Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
What 'underlying deficiencies of make' are you talking about? I don't see any such thing.
LCA: Disintermediating distributions
Posted Feb 6, 2008 23:45 UTC (Wed) by vapier (subscriber, #15768)
autotools allows you to create a build system that will work on any system that has a shell
and make. that make may not be GNU make. it may have bugs. its feature set may be severely
limited compared to what you're used to. many projects out there who set out to write their
own build system do so using GNU make which means they write code that Works For Them.
non-portable GNU-isms creep in which means the build system is no longer portable to many
targets which sort of defeats the original intent: making it portable.
Posted Feb 7, 2008 0:17 UTC (Thu) by vmole (guest, #111)
"Don't write portable Makefiles, use a portable make." I don't remember the source of that quote, but I do know that trying to deal with each broken vendor version of make leads to nothing pain and tears before bedtime. If you're building software, just install gmake and be done with it.
Posted Feb 7, 2008 0:38 UTC (Thu) by nix (subscriber, #2304)
Well, I know Paul D. Smith (the GNU make author) has said that in the
past, and I agree with him (for what very little it's worth).
Posted Feb 7, 2008 1:11 UTC (Thu) by stevenj (guest, #421)
Posted Feb 7, 2008 1:41 UTC (Thu) by stevenj (guest, #421)
(Although, to be fair, it's not like they could require GNU make to build. =)
Posted Feb 7, 2008 7:05 UTC (Thu) by madscientist (subscriber, #16861)
Although GNU make does come with an automake environment, it also provides a shell script that
can be used to build make. Obviously this will recompile and relink everything every time you
run it, but GNU make is not such a huge program that this is a problem. And once you've got
it built once, you can use that make for subsequent builds. Having this avoids the catch-22
of needing some make to build make.
That said, automake is awesome especially if you're developing highly portable tools, which
most of the GNU tools are. For GNU make I don't so much care about the portability aspects,
although that's nice too (but the shell script above would be enough of an "out" for GNU make
itself). The great thing about automake is all the default rules it provides, including
things like distcheck for building new packages, etc. These rules save huge amounts of time
and effort for package developers/maintainers.
Posted Feb 15, 2008 11:51 UTC (Fri) by ekj (guest, #1524)
The catch-22 of needing a make-program to compile gnu make isn't that much of a problem
You need a C compiler to compile GCC too. If you want it self-compiled you need to compile it
First use whatever C-compiler you happen to have lying around to compile GCC.
Then use your fresh gcc to compile gcc.
Posted Feb 15, 2008 22:00 UTC (Fri) by nix (subscriber, #2304)
With recent versions, thanks to the magic of top-level bootstrap, `make'
should give you a compiler and libraries byte-for-byte identical to what
you'd have got if you did the recompile-it dance. (Older versions wouldn't
have recompiled libiberty with the new compiler before linking that
compiler with it; top-level bootstrap has fixed that.)
Posted Feb 7, 2008 20:11 UTC (Thu) by vapier (subscriber, #15768)
it's really a mindset. do you tell every user their system sucks and they should install
Linux and up-to-date utilities ? or do you use automake and everyone out there can build your
project without a problem ? some people will choose the former while others will pick the
latter. in the latter case, automake is the only realistic solution.
Posted Feb 7, 2008 0:15 UTC (Thu) by stevenj (guest, #421)
Try using raw 'make' in a project with subdirectories sometime.
Another obstacle is that 'make' relies on 'sh' (a fairly primitive language) if you want to do anything nontrivial, and portable shell programming requires extreme care. (This is also a source of unfortunate complexity in autoconf and automake, but they provide tools to lessen your dependence on sh, at least.)
Posted Feb 7, 2008 4:39 UTC (Thu) by roelofs (guest, #2599)
$(MAKE) -C subdir
cd subdir && $(MAKE)
I believe even MS nmake circa 1990 supported that much, and it's not even close to a standard make. Every Unix make I've used (couple dozen) was better than that.
But it has been quite a few years since I messed with any of this stuff, so craniorectal impaction is always a possibility.
Posted Feb 7, 2008 10:05 UTC (Thu) by epa (subscriber, #39769)
Have a look at the article linked from the parent post. Calling one 'make' from another
makefile tends to lead to all sorts of crufty problems. The paper gives examples, and my own
experience certainly confirms it. That said, you can use make in a large project, just not by
Posted Feb 7, 2008 11:52 UTC (Thu) by cortana (subscriber, #24596)
> Try using raw 'make' in a project with subdirectories sometime.
Then you have already failed. Why on earth would anyone want to call make recursively? The
only reason I have ever heard is "because I don't understand what I'm doing, and I cargo
culted my build system from someone else, who also did not understand what he was doing".
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds