Today I had to compile a C project with over 200 .c files. If I'd used a Makefile I would have had to list every .c file (yes, I could auto-generate).
Instead I downloaded and used "Cons" - a little known perl utility for software construction. The "Construct" file became:
$cons = cons->new(
CFLAGS => '-O2',
LIBS => '-levent',
);
$cons->Program("dnsserver", <*.c>);
Default(qw(dnsserver));
So I went digging to see why the project hadn't been updated in a long time. Turns out the author didn't like perl OO so just stopped.I’d rather write something more akin to Ruby’s Rake in Perl. There’s TinyMake on CPAN, but it’s too limited and I didn’t like the code. I’ve already sketched it out a little but didn’t start yet.
Re:Rake
Matts on 2007-05-30T13:38:20
Rake frankly looks awful. No automatic dependency generation (as far as I can tell) and you basically have to write the compile commands yourself, rather than having the library do it for you. You might as well just write a Makefile!
Perhaps I've missed something though - I only went through the tutorial.Re:Rake
Aristotle on 2007-05-30T14:40:48
And that’s awful? Sure, it doesn’t do automatic dependencies, but Rake is Ruby and Rakefiles equally are Ruby – so unlike with Make, implementing arbitrarily complex functionality either in the build script or as a subclass of or some form of plugin for the engine is straightforward.
Cons’ architecture so fixated on one optimising for the compilation of C code that you can’t reasonably use it for anything else. If you want to repurpose it in any way, you have to hack on Cons’ guts… and have you seen them? It’s terrible. As far as I’m concerned, that’s far more awful than Rake.
What I want is a dependency resolver framework that comes with a basic implementation of abstract and simple file-based tasks, like Make, but whose recipes are written in a real language, and whose API has a servicable hooks to expand its behaviour and capabilities. Providing Cons-like features on top of that would be pretty easy and sane. Cons is not.
Re:Rake
Matts on 2007-05-30T14:48:33
Sounds like it's the implementation/internals you don't like (which I agree with) rather than the concept. I think that's spot on.Re:Rake
Aristotle on 2007-05-30T15:40:20
More or less, yeah. I have no beef with the featureset of Cons, just with the things absent from its featureset.
F.ex., I’ve wanted to write a build script for my website; it’s currently powered by
makeand libxslt’sxsltproctool. But I’d like to be able to use XML::LibXSLT instead, register a few XSLT extension fuctions right inside the build script, along with one or two functions to drive transforms, and then use those in my task recipes.If I were using Ruby and Rake, that would be very easy. With Cons, not so much.
So I’d want a closure-based API much like Rake’s, first of all; the C-specific features should be layered onto that as a separate module. It might not even need to be a build engine plugin – if there is a module to easily extract dependencies from C sources, simply
use-ing it in the build script and writing a bit of code to glue it into the rule registration would suffice.That’s the great thing about build scripts being written in a real language: you can actually drive the build engine computationally. Fowler mentioned this when he wrote about his experience in switching his bliki build process to Rake: he didn’t even need the Make-ish pattern match/automatic rule support that Rake provides. It was just as easy to write a loop to register rules.
Re:Rake
Matts on 2007-05-30T16:01:21
Yup - I agree with all of that.
I *think* Scons provides all that (and more).