Reggae v0.0.5 super alpha: A build system in D

[Atila Neves via Digitalmars-d-announce]

On Friday, 3 April 2015 at 17:40:42 UTC, Dicebot wrote:
> On Friday, 3 April 2015 at 17:17:50 UTC, Atila Neves wrote:
>> On Friday, 3 April 2015 at 17:13:41 UTC, Dicebot wrote:
>>> Also I don't see any point in yet another meta build system. 
>>> The very point of initial discussion was about getting D only 
>>> cross-platform solution that won't require installing any 
>>> additional software but working D compiler.
>>
>> I was also thinking of a binary backend (producing a binary 
>> executable that does the build, kinda like what ctRegex does 
>> but for builds), and also something that just builds it on the 
>> spot.
>>
>> The thing is, I want to get feedback on the API first and 
>> foremost, and delegating the whole 
>> do-I-or-do-I-not-need-to-build-it logic to programs that 
>> already do that (and well) first was the obvious (for me) 
>> choice.
>>
>> Also, Ninja is _really_ fast.
>
> The thing is, it may actually affect API. The way I have 
> originally expected it, any legal D code would be allowed for 
> build commands instead of pure DSL approach. So instead of 
> providing high level abstraction like this:
>
> const mainObj  = Target("main.o",  "dmd -I$project/src -c $in 
> -of$out", Target("src/main.d"));
> const mathsObj = Target("maths.o", "dmd -c $in -of$out", 
> Target("src/maths.d"));
> const app = Target("myapp", "dmd -of$out $in", [mainObj, 
> mathsObj]);
>
> .. you instead define dependency building blocks in D domain:
>
> struct App
> {
>     enum  path = "./myapp";
>     alias deps = Depends!(mainObj, mathsObj);
>
>     static void generate()
>     {
>         import std.process;
>         enforce(execute([ "dmd",  "-ofmyapp", deps[0].path, 
> deps[1].path]).status);
>     }
> }
>
> And provide higher level helper abstractions on top of that, 
> tuned for D projects. This is just random syntax I have just 
> invented for example of course. It is already possible to write 
> decent cross-platform scripts in D - only dependency tracking 
> library is missing. But of course that would make using other 
> build systems as backends impossible.

Well, I took your advice (and one of my acceptance tests is based 
off of your simplified real-work example) and started with the 
low-level any-command-will-do API first. I built the high-level 
ones on top of that. It doesn't seem crazy to me that certain 
builds can only be done by certain backends. The fact that the 
make backend can track C/C++/D dependencies wasn't a given and 
the implementation is quite ugly.

In any case, the Target structs aren't high-level abstractions, 
they're just data. Data that can be generated by any code. Your 
example is basically how the `dExe` rule works: run dmd at 
run-time, collect dependencies and build all the `Target` 
instances. You could have a D backend that outputs (then compiles 
and runs) your example. The "only" problem I can see is execution 
speed.

Maybe I didn't include enough examples.

I also need to think of your example a bit more.