DIP11: Automatic downloading of libraries

[Jacob Carlborg]

On 2011-06-21 14:12, Dmitry Olshansky wrote:
> On 21.06.2011 15:53, Jacob Carlborg wrote:
>> On 2011-06-21 12:04, Dmitry Olshansky wrote:
>>> On 21.06.2011 13:07, Jacob Carlborg wrote:
>>>> "target" works like this:
>>>>
>>>> 1. You call "target" passing in the name of the target and a block
>>>>
>>>> 2. "target" then call the block passing in an instance of a Target
>>>> class (or similar)
>>>>
>>>> 3. In the block you then specify all the necessary settings you need
>>>> for this particular target.
>>>>
>>>> You should only call "target" once for each target. So, if you pass in
>>>> "name2" instead of "name" you would create a new target. I haven't
>>>> figured out what should happen if you call "target" twice with the
>>>> same name.
>>>>
>>>> Also note that this would be sufficient:
>>>>
>>>> target "name" do
>>>> flags "-l-lz"
>>>> end
>>>>
>>> So it's a way to _create_ instances. I suspected there could be need to
>>> add some extra options to existing. Imagine creating special version of
>>> package, IMO it's better when all this extra is packaged at one place
>>> not in every block.
>>>
>>> BTW this doesn't look any better then possible D version:
>>>
>>> spec = Gem::Specification.new do |s|
>>> s.name = 'example'
>>> s.version = '1.0'
>>> s.summary = 'Example gem specification'
>>> ...
>>> end
>>>
>>> In any case there is now instance named spec, right? So user still have
>>> to manage some variables...
>>
>> No, no, no. Have you read my previous messages and the wiki? That
>> above syntax is used by Rubygems, Rake uses a similar and Orbit and
>> Dake will also use a similar syntax but will still be slightly
>> different. The concepts are the same, with calling a method and
>> passing along a block.
>>
>> The syntax used by Orbit doesn't actually need blocks at all because
>> you can only have one package in one orbspec. The syntax will look
>> like this:
>>
>> name "example"
>> version "1.0"
>> summary "Example gem specification"
>
> Very sensible, no arguments.
>
>>
>> Dake will have blocks in the syntax for its config files, this is
>> because multiple targets and tasks are supported within the same file.
>> The syntax will look like this:
>>
>> target "<name>" do
>> flags "-L-l"
>> product "foobar"
>> type :executable
>> end
>>
>
> Yes, this is the one I'm not entirely happy with, admittedly because
> it's a ruby script (and it's respective magic).
> I just hope you can embed Ruby interpreter inside dake so that user need
> not to care about having proper ruby installation (and it's correct
> version too).

Of course, Ruby will be embedded. I already have this working in Orbit. 
I'm very careful when choosing the dependencies my application/tools 
depends on. Another reason I'm not happy about switching to D2, then it 
would depend on libcurl.

>> In this case, <name> would refer to a single D file or a directory
>> with multiple D files. If you want to have settings for multiple
>> targets then you just put that code outside any of the blocks, at the
>> global scope (or pass a block to a method name "global", haven't
>> decided yet).
>
> Good so far.
>
>>
>> And similar for tasks:
>>
>> task "foo" do
>> # do something
>> end
>>
>> A task is just some code you can run from the command line via the tool:
>>
>> dake foo
>>
>> As you can see, no variables and no instances for the user to keep
>> track of. Seems that I actually do need to write down a complete
>> specification for these config/spec files.
>>
>
> I'm still looking for a clean version statements... but I'll just have
> to wait till you have the full spec I guess.

if version.linux || version.osx
     #
end

This allows to use versions just as bool values.

-- 
/Jacob Carlborg