DIP11: Automatic downloading of libraries

[Dmitry Olshansky]

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.

-- 
Dmitry Olshansky