reggae v0.5.0: new features in the D meta-build system

[Atila Neves via Digitalmars-d-announce]

On Tuesday, 22 September 2015 at 12:39:48 UTC, Per Nordlöw wrote:
> On Wednesday, 16 September 2015 at 14:07:17 UTC, Atila Neves 
> wrote:
>> http://code.dlang.org/my_packages/reggae
>>
>> What's new:
>> Atila
>
> If you want to build a really revolutionary *new* build system 
> you should turn reggae into a client-server-architecture that 
> listens to file moves/copies/notifications via inotify on 
> Linux. I'm not sure how the develop/builder interface would 
> look like then, however. A web-client would be one way.

That idea is in the TODO.txt of the project. There's a 99.9% 
chance I won't bother.

I just benchmarked a toy auto-generated project of 30'000 D 
files, because I wanted to profile and optimise the binary 
backend against ninja and tup. I'm doing this by measuring the 
overhead of checking all of these files for modification 
timestamps, since actually compiling and linking take much 
longer. The overhead for ninja is 0.18s. Tup does it even faster. 
My current binary backend spends all of 0.3s, and that's what I 
was trying to optimize. Make, however... 22s I think.

It would seem obvious that using something like inotify would be 
incredibly fast, but in practice it's irrelevant. Well, it's 
irrelevant for pretty much every project out there. I'm 
incredibly sensible to how long my feedback loops are, but if a 
30k file project takes under a second to check, I really don't 
care.

Now, you may say that my toy project doesn't accurately represent 
real life. But I've used ninja on a real C codebase of 40M lines 
spread over ~14k files. This is much larger than most people will 
ever deal with. A no-op build took 1s.

Make is slow. Just don't use make. The ninja, tup and binary 
backends of reggae are fast enough. Incidentally, this is why 
ninja didn't try to get faster. It doesn't need to.

I might consider a system where you don't even have to tell the 
computer to build anything. I'm not even sure that's that useful. 
Maybe it's just the way I work, I don't know.

> This however does not rebuild the dependency tree between 
> invokations which is a serious limitation. I believe reggae 
> could be even smarter here.

It already is ;)

> I've spent the last two years designing and implementing a 
> SCons-based build system at work. Involving, among others, 
> adding support for Ada and auto-detection of include-paths as 
> you have done in reggae.

Feel free to issue a PR for Ada auto-detection for reggae. :)

> I you want any advice on this matter please contact me. I'd be 
> glad to be of service.

Send me an email, I'm more than happy to waffle away about build 
systems.