On Thu, May 24, 2001 at 09:11:43PM +0200, RADICS Peter wrote:
> Hello gstein,
>
> Could you explain some rationale behind this rewamping of the make
> process?
No.
Just kidding... :-) As Karl pointed out, the paper on "Recursive Make
Considered Harmful" is actually quite a valid paper. The new build system is
a lot faster than before. We also have just a single Makefile to maintain,
rather than two dozen scattered across the system.
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. 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.
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 automake system also required GCC to be present to deal with dependency
generation. And you couldn't turn that off! I have no idea how people were
building SVN on AIX systems using the xlc compiler (maybe nobody tried?).
The new dependency generation is portable, and also much more finely tuned.
On that last bit: GCC's dependencies included every file included, not just
the SVN files. This *really* pissed me off. Whenever I would go and
configure APR, it would touch include/apr.h. BAM! My entire Subversion
project would recompile. I've been lazy about moving to my faster
development machine, so that is actually quite painful. I've gotten pretty
used to avoiding unnecessary updates to APR. That's just wrong. The tools
should work *for* me, rather than against me. We want dependencies on the
stuff that we change, and use the presumption that our building blocks
(Neon, APR, etc) only change their APIs in compatible ways.
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.
Automake also has some weird dependencies on a ChangeLog file being present.
That is silly. We might *distribute* one, but in day-to-day development?
Screw that.
The underlying point is that Automake may be fine for FSF/GNU projects,
which all adhere to a very specific set of rules. But for your Average Joe
project, we have our own policies and desires. Automake isn't flexible
enough for that.
Then there is that whole recursion thing I mentioned. We get speed and
clarity with the new system. Removing automake and its bazillion
substitutions has also dramatically sped up autogen.sh and the last step of
./configure.
Lastly, we have a lot better control over all the details of building,
installation, cleaning, etc. In particular, the "make check" stuff is a big
win. We were replacing that in all of the Makefiles for the test
directories. But they were all inconsistent. And they didn't work together.
etc etc.
It also just feels simpler. Need to change something? Go and tweak
Makefile.in and it fixes the whole system. Or maybe adjust gen-make.py to
alter how it produces build-outputs.mk.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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