DIP11: Automatic downloading of libraries

[Dmitry Olshansky]

On 20.06.2011 16:35, Dmitry Olshansky wrote:
> On 20.06.2011 15:35, 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.
>>
>
> Well, everything about compile-time introspection could be labeled 
> like a hack. In fact I just seen the aforementioned "hack" on a much 
> grander scale being used in upcoming std module, see std.benchmarking:
> https://github.com/D-Programming-Language/phobos/pull/85/files#L1R577
> And personally hacks should  look ugly or they are just features or at 
> best shortcuts ;)
>
> Personal things aside I still suggest you to switch it to D2. I can 
> understand if Phobos is just not up to snuff for you yet (btw cute 
> curl wrapper is coming in a matter of days). But other then that... 
> just look at all these candies ( opDispatch anyone? )   :)
> And even if porting is a piece of work, I suspect there a lot of 
> people out there that would love to help this project.
> (given the lofty goal that config would be written in D, and not Ruby)
>
Just looked through the source , it seems like you are doing a lot of 
work that's already been done in Phobos, so it might be worth doing a 
port to D2. Some simple wrappers might be needed, but ultimately:
util.traits --> std.traits
core.array --> std.array + std.algorithm
io.path --> std.file & std.path
orgb.util.OptinoParser --> std.getopt

util.singleton should probably be pulled into Phobos, but a thread safe 
shared version.

-- 
Dmitry Olshansky