Prototype buildsystem "Drake"

Nick Sabalausky a at a.a
Fri Jul 15 15:09:49 PDT 2011


"Jacob Carlborg" <doob at me.com> wrote in message 
news:ivpfoa$uu7$1 at digitalmars.com...
> On 2011-07-14 21:06, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob at me.com>  wrote in message
>> news:ivme1u$31i8$1 at digitalmars.com...
>>>
>> [...snip...]
>>> In D, with this syntax:
>>>
>>> target("foo.d", {
>>>      buildflags ~=  "-L-ldwt";
>>> });
>>>
>>> target("main.d" {
>>>      buildflags ~=  "-release"
>>> });
>>>
>>> "buildflags" would probably be a global function or an instance method. 
>>> If
>>> this should work "buildflags" needs to keep some data structure with
>>> buildflags for each target. This seems quite complicated, making sure 
>>> the
>>> correct build flags are used with the correct target.
>>
>> That's an interestng idea. I think it could be done fairly easily by 
>> having
>> Drake invoke the delegates indirectly like this:
>>
>> Target t; // global
>> void invokeBuildStep(Target currTarget, {type} dg)
>> {
>>      t = currTarget;
>>      dg();
>>      t = null;
>> }
>
> The functions invoked in the delegate till use the global target? Seems 
> this would work.
>

That's the idea, yes.

>> Only thing though, is if there's any special members added to the Target
>> subclass being used, the user would have to cast 't' to access them. Then
>> again, that's an issue in the current design, too. I'll have to think 
>> about
>> this...
>
> Maybe in that case it's better to pass the target to the delegate. Just 
> provide several overloads of the function taking the delegate.
>

Perhaps. Something to think about anyway. Although, IIRC, I think already I 
ran into some trouble with IFTI, type inference, overloading, etc. when 
trying to do something like that... But anyway, all stuff to think about...




More information about the Digitalmars-d mailing list