On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards
instead of listing all the sources" and then wrote in response to my
reply:
> http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards
>
> is your answer.I think their "answer" is lame; we have already sacrificed portability
because we are using enough of gmake-only functionality because we
cannot depend on the system "make" being anything useful, yet gmake is
portable, and hence, the "standard".
I agree completely.
The thing about "distribute only what you list", well... maybe, but the
way "WE" do distribution is (I believe) checkout, build, test, make
clean, make dist. That way, you *know* that what you're distributing
actually works. But I'm not the distro person, that's John.
Well, automake changes all that. Right now it takes John 1-2 weeks to do
a "distro". automake can produce a VALIDATED distribution automatically
with only CPU time involved. The "distcheck" target builds a
distribution candidate, produces a tar.gz of it, unpacks it, rebuilds
it, and if everything is okay, the tar.gz is good to go. This will find
ALL KINDS of subtle errors and a big part of getting the distribution
right is setting up the _SOURCES variables to list things correctly.
There's some other points not mentioned in the automake documentation.
(1) It turns out to be incredibly handy to have control over what
actually gets built when you're doing multi-platform stuff. You can
add files to directories that WON'T be compiled by anyone until you
commit changes to the Makefile.am. This allows me to commit stuff on
one platform, check it out on another, and another, and ..., build them
all and only modify the Makefile.am when its working everywhere.
(2) Despite (1) above, we'll probably try to figure out a wildcard
approach for directories that are strictly portable. I.e. we'll keep
the list of files for lib/System and anything else that needs to be
tested on multiple machines but use a wildcard in the places that are
pure/vanilla C++ and a check-in on one platform is pretty much
guaranteed to work everywhere.
(3) Another thing you'll run into is the FINDPATH macro function in the
Makefile.rules.am. This is a hack currently implemented for simplicity
in the tools/*/Makefile.am files. What we eventually want to do is put
all the libraries into one directory and use a -L option to
find them.
(4) We've recently discovered that executable size is about 1/2 with
automake build. This might be due to the use of -O2 option, but since
its mostly debug output in the executables, this is unlikely. There was
probably an error in the existing makefiles that duplicated the debug
info (just guessing).
(5) Automake isn't a panacea, it has its warts like anything else. I
just happen to think that the benefits out weigh the costs. We get
perfect installs, simplified distribution builds (everyone can do it),
automated testing ("make check"), perfect dependency generation, etc. As
for warts, you've already asked the most frequently raised objection
(listing source files). There are a few others, like RANLIB (can't
override it on a per-target basis). To me, these are small price to pay
for the benefits. There aren't many other things that automake doesn't
do exceptionally well.
In any event, this is all a grand experiment. We're doing this to see if
it is (a) possible, (b) worthwhile to convert to automake. We need to
make a list of pros and cons and that can only be done after people have
tried it and used it for a while.
Reid.