DIP11: Automatic downloading of libraries

[Dmitry Olshansky]

On 21.06.2011 1:36, Jacob Carlborg wrote:
> On 2011-06-20 22:45, Dmitry Olshansky wrote:
>> On 20.06.2011 23:39, Nick Sabalausky wrote:
>>> "Dmitry Olshansky"<dmitry.olsh at gmail.com> wrote in message
>>> news:itn2el$2t2v$1 at digitalmars.com...
>>>> On 20.06.2011 12:25, Jacob Carlborg wrote:
>>>>> On 2011-06-19 22:28, Dmitry Olshansky wrote:
>>>>>
>>>>>> Why having name as run-time parameter? I'd expect more like (given
>>>>>> there
>>>>>> is Target struct or class):
>>>>>> //somewhere at top
>>>>>> Target cool_lib, ...;
>>>>>>
>>>>>> then:
>>>>>> with(cool_lib) {
>>>>>> flags = "-L-lz";
>>>>>> }
>>>>>>
>>>>>> I'd even expect special types like Executable, Library and so on.
>>>>> The user shouldn't have to create the necessary object. If it 
>>>>> does, how
>>>>> would the tool get it then?
>>>>>
>>>> If we settle on effectively evaluating orbspec like this:
>>>> //first module
>>>> module orb_orange;
>>>> mixin(import ("orange.orbspec"));
>>>> //
>>>>
>>>> // builder entry point
>>>> void main()
>>>> {
>>>> foreach(member; __traits(allMembers, orb_orange))
>>>> {
>>>> static if(typeof(member) == Target){
>>>> //do necessary actions, sort out priority and construct a
>>>> worklist
>>>> }
>>>> else //static if (...) //...could be others I mentioned
>>>> {
>>>> }
>>>> }
>>>> //all the work goes there
>>>> }
>>>>
>>>> Should be straightforward? Alternatively with local imports we can
>>>> pack it
>>>> in a struct instead of separate module, though errors in script 
>>>> would be
>>>> harder to report (but at least static constructors would be
>>>> controlled!).
>>>> More adequatly would be, of course, to pump it to dmd from stdin...
>>>>
>>> Target would be part of Orb. Why not just make Target's ctor register
>>> itself
>>> with the rest of Orb?
>>>
>>>
>> Nice thinking, but default constructors for structs?
>> Of course, it could be a class... Then probably there could be usefull
>> derived things like these Executable, Library, etc.
>
> I really don't like that the users needs to create the targets. The 
> good thing about Ruby is that the user can just call a function and 
> pass a block to the function. Then the tool can evaluate the block in 
> the context of an instance. The user would never have to care about 
> instances.
>
I'm not getting what's wrong with  it.  Your magical block is still 
getting some _name_ as string right? I suspect it's even an advantage if 
you can't type pass arbitrary strings to a block  only proper instances, 
e.g. it's harder to mistype a name due to a type checking.

What's so good about having to type all these name over and over again 
without keeping track of how many you inadvertently referenced?

Taking your example, what if I typed name2 instead of name here, what 
would be the tool actions:
target "name" do |t|
     t.flags = "-L-lz"
end

Create new target and set it's flags? I can't see a reasonable error 
checking to disambiguate it at all.
More then that now I'm not sure what it was supposed to do in the first 
place - update flags of existing Target instance with name "name" ? 
Right now I think it could be much better to initialize them in the 
first place.

IMHO every time I create a build script I usually care about number of 
targets and their names.

P.S. Also about D as config language : take into account version 
statements, here they make a lot of sense.

-- 
Dmitry Olshansky