Prototype buildsystem "Drake"

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:ivp1gd$500$2 at digitalmars.com...
> On 2011-07-14 21:50, Nick Sabalausky wrote:
>> "Jacob Carlborg"<doob at me.com>  wrote in message
>> news:ivng77$305d$1 at digitalmars.com...
>>> On 2011-07-13 23:52, Nick Sabalausky wrote:
>>>> Hmm, yea, configure didn't even occur to me. I think it could acually 
>>>> be
>>>> done as just another File target that everything else depends on. Only
>>>> thing
>>>> is then you'd have to save/load the configuration file manually, so 
>>>> maybe
>>>> there should be some convenience mechnism for that (Maybe utilizing
>>>> Jacob's
>>>> Orange serialization library once that rewrite is done? Or maybe that
>>>> would
>>>> be overkill? Is there some INI-file util, or am I just imagining that?)
>>>
>>> What about doing something like DSSS/rebuild does. There are config 
>>> files
>>> for dmd, ldc and gdc on various platforms. You can choose to invoke
>>> different compilers and it will use the config file for that particular
>>> compiler on the current platform.
>>>
>>
>> One of my main goals for Drake is that using any old random tool (besides
>> just building D code) doesn't feel like an afterthought. That
>> DSSS/rebuild-style approach doesn't seem like it would scale particularly
>> well in that direction. I think whatever solution is used needs to work 
>> just
>> as well for the user's own custom tools as it does for DMD/LDC/GDC. Then,
>> any D-specific simplifications/improvements that are made should be built 
>> on
>> top of that. For example, we could provide a function the user calls from
>> within their "configure" step that automatically handles D-specific
>> configuring (And yea, maybe we could even automatically provide a default
>> "configure" that already calls that function.)
>
> Ok, have you thought about how this will look (in code) and behave?
>

Not extensively, but here's what I have in mind so far. In an early initial 
version of Drake, it would be like this:

    task("configure", "drake.conf");

    file("drake.conf",
        (Target t)
        {
            // Do all configuring here and save to drake.conf
        }
    );

Then, Drake can add built-in tools for configuring DMD and saving/loading a 
configuation file:

    task("configure", "drake.conf");

    file("drake.conf",
        (Target t)
        {
            auto configure = configureDMD();

            // Do all custom configuring (if any) here,
            // adding data to be saved into 'configure'.

            configure.save(t.name);
        }
    );

And finally, all that boilerplate can be hidden away and handled 
automatically by Drake:

    // Completely optional:
    file("drake.conf",
        (Target t)
        {
            // Do all custom configuring here (if any is even desired),
            // adding data to be saved into global 'configure'.
        }
    );

At that point, the automatic configuring could optionally be disabled like 
this:

    defaultConfigure = false;

    // Completely optional, completely manual:

    task("configure", "drake.conf");
    file("drake.conf",
        (Target t)
        {
            // Do all configuring here and save to drake.conf.
            // The 'configureDMD' and 'configure' can still be
            // used manually.
        }
    );