> As Karl pointed out, the paper on "Recursive Make Considered
> Harmful" is actually quite a valid paper.
Not everyone agrees. The examples used in that paper are bizarre and
uncommon, generally involving mutual dependencies between directories.
If we're only considering the case where the user runs "make" at the
top level, then recursive make works just fine as long as dependencies
between directories only go one way. And if they don't, your build
system is spaghetti anyway.
Moreover, having a single Makefile is less functional in that you
can't run "make" in a subdirectory to build only targets in that
subdirectory, as is often convenient. (And it's not just convenient
to save runtime; it's convenient because (1) the world isn't an
optimal place, and sometimes the build blows out in a directory you
didn't care about, and it's easier to just build subcomponents than to
fix the problem, and (2) you're often already in the subdir in a
previously completed build tree, making some change, and don't want to
jump back to the top level to test it.)
> Automake also produces Makefiles that require GNU make. That is a
> big pain for the FreeBSD users out there, and some other
> fringe/older OSes (I've got to imagine that SunOS or AIX users will
> be happier).
The most recent release of automake has a bug such that if you don't
use --include-deps, you get a rule which depends on both gmake and
gcc. It's a pretty egregious bug, but it's also trivial to work
around (by using --include-deps, which is the default for the automake
"dist" target).
> On that last bit: GCC's dependencies included every file included,
> not just the SVN files.
(Your statement is too expansive; the dependencies shouldn't include
system headers.) How is it supposed to know that the APR files are
part of a different project? How do you know that a change to apr.h
doesn't affect the files which include it? Why doesn't apr's
configure script avoid touching apr.h when there is no actual change?
> Another thing about automake is its insane predilection for
> rebuilding the ./configure script and associated files. Any change
> to those files, and everything goes to seed. I think it is an
> absolute horror for a Makefile to ever run ./confiure, for any
> reason. That is a user operation, not something to be left to a
> Makefile. Same thing for generating ./configure from the
> configure.in file -- we have autogen.sh to do that; the Makefile
> shouldn't ever try it. But you can't change that behavior in
> Automake.
Right with you up until the last line; there's an AM_MAINTAINER_MODE
option to change that behavior.
> There were some things that we wanted to do which were a giant pain
> when dealing with those scattered Makefiles. For example: adding the
> --silent flag to every libtool line.
I'm not sure why Subversion should be different from pretty much all
other libtool-using programs in regards to the --silent flag, but I'm
also not sure what the problem is; we seemed to be doing this before
the build system change via the definition of LIBTOOL.
> Or a rule for creating the .la-a files needs when we do a
> static-link install of mod_dav_svn into an Apache source tree.
This problem is over my head, but I can certainly see how changing the
object generation rules would be a pain in automake. I'm not actually
a big fan of automake and don't use it in my own projects, but I do
use recursive make, and have never seen a compelling reason not to.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:30 2006