DIP11: Automatic downloading of libraries

[Nick Sabalausky]

"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?