| |||||||||||||
That's why I've said "not just distribution guys".That's why I've said "not just distribution guys".Posted Nov 11, 2011 16:48 UTC (Fri) by nix (subscriber, #2304)In reply to: That's why I've said "not just distribution guys". by cmccabe Parent article: libabc: a demonstration library for kernel developers
FWIW, autotools scales reasonably well. It only really falls over speed-wise when you start using things like gnulib, which because they test for every bug you can possibly imagine tend to take minutes to run a multimegabyte configure script.
The actual build, well, since cmake generates makefiles, the problem must be something other than cmake-versus-GNU Make. And it is. Firstly, a lot of projects, especially older projects, are rife with recursive make, which the advent of parallel compilation has made particularly clear was a bad idea from the start. But nonrecursive makefiles aren't hard to write with Automake, even for larger projects (see e.g. ImageMagick for an example). The payoff is just relatively low for the work that needs doing. The second problem is Libtool, which thought it is much faster than it was, really works at the wrong level: it should be part of Automake, so that the generated makefiles directly contain the appropriate magic incantations to generate shared libraries. Unfortunately if you fix that you break the people who are running Libtool directly, and those were its original user base: Automake integration came later.
(Log in to post comments)
That's why I've said "not just distribution guys". Posted Nov 16, 2011 0:17 UTC (Wed) by cmccabe (guest, #60281) [Link]
Yeah, but having to cram everything into one giant Makefile sucks. It's like putting all your code into one .c file because your compiler is to dumb to handle multiple files. It's 2011. We shouldn't have work around these kind of tool limitations.
That's why I've said "not just distribution guys". Posted Nov 16, 2011 2:53 UTC (Wed) by nix (subscriber, #2304) [Link]
You don't have to cram everything into one giant makefile. You just say
include $(shell find . -mindepth 2 -name Makefile)
then have subsidiary makefiles say, in part, something like
ifeq ($(words $(MAKEFILE_LIST)),1)
And now you have lots of independent fragments of makefiles drawing on a common library declared in the toplevel makefile, new ones are automatically picked up, the makefiles can themselves be automatically built using make rules and the changes picked up, and anyone typing make in subdirectories gets an automatic make from the toplevel instead. (With further trivial adjustments you can arrange to automatically build only the subdir's targets, and automatically compute the toplevel makefile, and have all of that boilerplate inserted with a single $(eval ...) so the people writing those subsidiary makefiles never need to know all this stuff.)
Not only is this not hard, it is stuff which it is quite easy to autogenerate if you so desire. It is also stuff which is designed into GNU Make (hence the auto-reloading feature of "include" if the included makefiles are rebuilt), so it is not in any way a "workaround".
(Non-GNU makes are often a lost cause in this area. Anyone who's not using GNU Make is just trying to be difficult by this point: GNU Make runs everywhere and is more capable than just about all the competition.)
That's why I've said "not just distribution guys". Posted Nov 16, 2011 21:55 UTC (Wed) by cmccabe (guest, #60281) [Link]
I believe you just described how the Android build system works, except that they use a Python script to locate Android.mk files, rather than the find command. If you could find a way to apply this trick to autoconf projects, you probably could speed up quite a few builds-- at the cost of making things even more complex. The other alternative is just to use CMake, which will do this all for you, without any boilerplate. But I guess you're probably sick of hearing about that by now :)
|
|||||||||||||