DIP11: Automatic downloading of libraries

[Andrei Alexandrescu]

On 6/20/11 6:35 AM, Jacob Carlborg wrote:
> On 2011-06-20 10:59, Dmitry Olshansky wrote:
>> 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...
>
> I had no idea that you could do that. It seems somewhat complicated and
> like a hack. Also note that Orbit is currently written in D1, which
> doesn't have __traits.

std.benchmark (https://github.com/D-Programming-Language/phobos/pull/85) 
does that, too. Overall I believe porting Orbit to D2 and making it use 
D2 instead of Ruby in configuration would increase its chances to become 
popular and accepted in tools/.

Andrei