Prototype buildsystem "Drake"

Nick Sabalausky a at a.a
Thu Jul 14 12:15:15 PDT 2011


"Jacob Carlborg" <doob at me.com> wrote in message 
news:ivm9lq$2q1d$1 at digitalmars.com...
> On 2011-07-13 23:41, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob at me.com>  wrote in message
>> news:ivke5k$2m78$1 at digitalmars.com...
>>>
>>> The "drakfile" function seems unnecessary. I would use a string import 
>>> (or
>>> what it's called), importing the whole build script into a method in a
>>> class. All code in the "drakefile" function would instead be at top 
>>> level.
>>>
>>
>> I'm not entirely opposed to that idea, but here are the (perhaps minor?)
>> reasons I did it this way:
>>
>> - Using "import" inside functions is brand-new and likely still buggy. 
>> And
>> unless I'm mistaken, I think there's other problems that still exist with
>> using the same code inside a function as outside (such as some
>> order-of-declaration limitations, IIRC). I wanted to get moving on 
>> something
>> that would work reliably right away without being too sensitive to 
>> bleeding
>> edge-cases. I figured if all that gets sorted out later on, then maybe a
>> Drake v2 could go that route.
>
> I was referring to this:
>
> void main ()
> {
>     writeln(import("main.d"));
> }
>
> This has been working as long as I've been using D. It works in D1 as 
> well.
>

I assume you meant "mixin" instead of "writeln".

What I meant is that, suppose wr have this:

    // internal_to_drake.d:
    void main()
    {
        mixin(import("main.d"));
    }

    // main.d:
    import blah;
    // rest of buildscript...

Then that becomes:

    void main()
    {
        import blah;
        // rest of buildscript...
    }

And *that's* a brand-new feature. And I think there may be some other 
things, too, that might still be a little buggy if they're stuck inside a 
function like that.


>> - I wasn't sure if a D file that isn't strictly a proper D file would be 
>> too
>> weird, too confusing, too magical, or would confuse the fuck out of 
>> advanced
>> IDE's.
>
> I have no idea how an IDE would behave with an incomplete file like that. 
> I pretty sure this only matters if the IDE does some semantic processing, 
> i.e. something more than just syntax highlighting. Textmate, which 
> basically only does syntax highlighting, has no problem with an incomplete 
> D file.
>

Right, but a lot of people use fancy IDE's like Eclipse and Visual Studio.


>> If those are really just totally bullshit reasons, then I'm certainly 
>> open
>> to the idea of doing it as you suggest.
>>
>>
>>> Most of the functions called in the build script should be instance
>>> methods, this will allow to use threading, possible invoke multiple
>>> targets/tasks simultaneously and running several build scripts
>>> simultaneously.
>>>
>>
>> My understanding is that with thread-local being the default, they 
>> *don't*
>> need to be instance methods to be thread-safe.
>>
>> Also, dependency-checking and task-invocation (once they're implemented)
>> won't occur at all until *after* the drakefile() function completes. The
>> target!...(...) function merely defines the targets, adding them to an
>> internal list - nothing more. So I'm not sure that's not really a
>> thread-appropriate matter.
>>
>> Not really sure what you mean about running several build scripts
>> simultaneously. The buildscript gets compiled into an exe, so the
>> buildscripts all run in separate processes anyway.
>
> Hm, it may actually not be a problem. I'll have to give this some more 
> thought, if there is any problem or not. It's probably me doesn't think 
> straight.
>

Maybe you're thinking D1? I *think* the thread-local-by-default is D2-only 
(though I'm not certain).





More information about the Digitalmars-d mailing list