DIP11: Automatic downloading of libraries

[Dmitry Olshansky]

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).

> 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.

-- 
Dmitry Olshansky