Inspired by Ian, this past weekend I took a look at replacing the auto tools with GNU make code.
Replacing automake turns out to be very easy. And, given that GNU make is everywhere now, I think it is well past time to do this.
It took about 250 lines of code to get C and C++ compilation — with dependency tracking — install, clean, libraries, and programs working.
Of course, this is just the beginning. There’s still shared libraries (ugh), dist, distcheck, and a host of smaller things.
Still, the result is quite nice. The resulting user Makefiles are pretty similar — but, unfortunately, not identical. With a bit of help it could be ready for real use by Christmas. Write me if you’re interested.
The long term goal, of course, is to unify all three tools. I’ve also got some prototype GNU make code to do some configure-style checking, based on some earlier prototyping by Ben Elliston. This is less fully baked, and there are some problems I haven’t solved. But, I think the idea is sound.
In my view the plan would be to finish automake and libtool functionality in the new code, then move on to adding configuration support. The latter can be done incrementally. In the end, we will have replaced all the tools with something better, without undue disruption.
The most important decision — what to name it — is still open. Submit your ideas.
25 Comments
Clearly the name should be the last word of Ian’s blog post.
Personally, if I was going to pick something to assume it was there, it would be Python. Make suffers from the fundamental problem of still being based on execution of shell scripts.
waf looks like a decent build system:
http://code.google.com/p/waf/
Impressive. You will however be removing one of the main supporting reasons to add plug-ins to GCC. People will no longer be able to claim that it takes 4 months to learn how to add files to the build system.
Hmm… neomake, novomake… Something that has deconstructionist connotations as well as being at the vanguard of makefile technology.
Zardoz 😀
I am so encouraged by your post. Count me as a Gnome developer that would love to use what you have described. The auto tools configuration in my module is nearly six years old now and so layer-upon-layer of cruft that I can rarely discover the source of various distribution problems we are having.
As for the Python comment, please, not yet another language to keep up on. Keeping up on six or seven is hard enough…
Yo.
Doing this – just for Monotone, not for the general case – has been on my To Do List for months. I’m definitely interested in helping. I have no time to write actual code until January, but I can poke at things and make suggestions.
“finish” as that’s actually what it’s doing. 😉 Finishing the build, and finishing off auto*
I knew there was a reason I didn’t kill you for automake! I nominate “remake” (ok, not seriously…) I also cast my vote against anything ending in -ng, 2.0, or v2.
Perhaps a good aim would be to have it shipped with GNU make (as include files installed into a searchable standard directory); that would minimise the amount of cruft that projects would have to include in their source packages.
That also avoids the naming problems — it just becomes “GNU make version foo or later”. 😉
I had this thought recently; I’m happy that someone of your caliber is actually doing it.
I’d be interested in trying such a system. I’ll be waiting for a public prototype 🙂
Could you set up a repository somewhere?
I believe this just waits to be done. We changed to gnu make with includes instead of autotools and all is good (well … better).
Our ./configure is a python script. It generates a config.mk which is also included.
Libtool may be a challange. We use gcc/linux systems only where you can just use gcc -shared (-pic), so it’s quite simple. I don’t know about other systems.
@Colin: And you would suggest replacing something that suffers fundamentally (your words) from being based on the execution of shell scripts, with something that would be equally fundamentally cranky due to being based on the execution of Python scripts?
I would say this is a good instance of a shiny new hammer combined with reckless neophilia.
Don’t we already have SCons? What a rousing success that has been. An useful tool it may be, but a light(er)weight replacement for Make it ain’t.
Mark Wielaard said:
> Clearly the name should be the last word of Ian’s blog post.
I second this idea.
> It took about 250 lines of code to get C and C++ compilation — with dependency tracking — install, clean, libraries, and programs working.
Eh, what?
250 lines to compile some files?
I don’t want to write or copy/paste 250 lines just to compile some files. It should require much less lines/text.
Have a look at how cmake does it.
i like ‘quagmire’ as a name, other names that seem apropos: retool (as in what you are doing to autotools: retooling it), autobake, or simply: sanity.
any luck on dealing with generated include files??
surprisingly, it is this and not shared lib issues that I see as the main hurdle.
@Anonymous Expert Programmer: make works pretty well. I believe the idea is to write a new configure and to add make-code to simplify installation and building of standard objects etc., not to write a make-replacement.
I am not sure you took this into account, but does your tool take into account cross building?
Wow, lots of replies! Cool.
I’ll set up hosting for it soon. Then we can discuss the design decisions, direction, etc. One thing that helped automake a lot was deciding on some stylistic things (eg, naming of variables in Makefile.am) very early. While I think automake’s input language is pretty reasonable overall, quagmire (I love that name) can’t be fully automake compatible, so we have some leeway to take a new tack.
@bkoz: I think, generally, that order-only dependencies provide a pretty decent solution to generated headers. This is a newish feature in make.
@eddyp: Yes, cross building will be supported. At least for the build part of auto* replacement, this is easy anyway.
@Adam: yeah, that is a cool idea. I wonder if the make maintainers would agree.
I tried registering “quagmire” at google code, but it turns out that this is the name of a (zombie) project at sourceforge. I clicked the button to ask the sourceforge project owners for permission, but I don’t have high hopes that they will respond 🙁
Maybe another name is needed. Or maybe a different hosting site.
Tom the people wait with bated breath. Push a git/bzr/.. repo somewhere with some code! ;-))
Launchpad’s a fine hosting service, if you have bzr branches. “Quagmire” appears available for registration there: https://launchpad.net/projects/?text=quagmire
Andy — thanks for the encouragement.
I will do this very soon. I’ve been procrastinating a bit due to other events in my life.
Very interesting. I’ve been playing with this type of thing in gmake for ages, trying really hard to stay within the bounds of make. It generally works pretty well across my platforms of interest (Mac, Linux, Windows).
Please let me know when you get quagmire hosted somewhere.
Hi Ian,
I just bumped into this post. I don’t know if you ever completed your work, but in case you still think this is a good idea, take a look at https://github.com/c3d/make-it-quick,
Cheers