On Don, 2008-06-12 at 19:25 -0500, Rob Landley wrote: > On Thursday 12 June 2008 11:12:13 Robert P. J. Day wrote: > > On Thu, 12 Jun 2008, Mike Frysinger wrote: > > > On Thu, Jun 12, 2008 at 11:50 AM, David Woodhouse wrote: > > > > If we just made people write portable code and proper Makefiles, > > > > it would be less of an issue :) > > > > > > people cant even write proper *native* makefiles. mtd-utils for > > > example ;). > > > > meooowww! :-) but at the risk of dragging this even further > > off-topic, i am *constantly* asked by people how to set up makefiles > > for their software project, and what would be nice is a small > > collection of examples of a makefile (or makefiles) done *right*. as > > in, > > Make doesn't scale. > > 99% of the builds in the open source world are "make all", and most of the > smaller projects build natively on modern dual processor 2ghz laptops in > under 10 seconds anyway. > > The larger projects with significant build times usually find that make > doesn't suit their needs, so that they write some other build system. > Sometimes they do it on top of make, such as the kernel's kbuild. Sometimes > they use another language like apache's ANT. Sometimes they roll their own "ant" is also only "make reimplemented in Java" (or did I miss something). I see no win here. > in C (anybody remember X11's imake?) KDE switched to cmake: That generated "only" a Makefile IIRC. [...] > Current compilers have a "build at once" mode where they suck the whole > project in and run the optimizer on it at once, resulting in noticeably > smaller and faster output at the expense of needing buckets of memory to hold > all the source code and intermediate structures in memory at once. The main > roadblock to making use of this? Ripping out the existing makefiles and > replacing them with a very small shell script that does something similar > to "gcc *.c". > > The first question you should be asking when doing a new build system from > scratch is probably "should I really be using make"? > > > properly recursive, > > Recursive make considered harmful: > http://aegis.sourceforge.net/auug97.pdf ACK. > How is needing to call make recursively _not_ just another way of sayng "the > dependency checking make does, which was the central idea behind its design, > is a lost cause and we need to jettison it to do builds"? The problem is that build systems have (at least) two layers: - the lower are the usual apps and libs and kernel ... bringing their working Makefile's with them. - the upper layer needs to build the kernel, libs and apps. This needs usually a defined sequence and set of consistent parameters. But the lower layer doesn't "export" it's local available rule base so the `make` (or shell script) on the upper layer can't use it and one must therefore `make -C $tooldir` - even if there is absolutely nothing to do. Of course the upper layer may remember if an lib/app has been build to avoid 60% of all "obviously" useless `make -C` calls. But that doesn't solve any problem really. > I just did a "make distclean" on a qemu tree I had lying around. On my 1.7 > ghz 64 bit laptop, it took 9.2 seconds to figure out it had nothing to do, > just because it had to recurse into so many subdirectories to do it. "Recursive make considered harmful" Or you need more RAM and faster disks;-) Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
