* Keith MARSHALL wrote on Wed, Nov 16, 2005 at 11:51:53AM CET:
> Ralf Wildenhues wrote, quoting me:
> >> and should work just the same. It's this sort of unnecessary
> >> verbiage that puts me off using automake.
> > Au contraire. I believe *one variable for one* use is a good
> > concept.
> Well, I'm afraid that we will just have to agree to disagree on
> this point.
Well, nothing bad about that. Would be boring if everyone agreed to
everything all the time. :)
> Quoting the autoconf 2.59 info docs:
> As I interpret that, the standard way to specify a prefix is to
> use configure's `--prefix' option, but that may be altered when
> invoking `make' to *build* the package, and may be overridden
> again, to specify an alternative installation point, by running
> `make prefix=<alt_install_prefix> install'; this is also the
> technique implicitly mandated by the GNU Coding Standards:
> | Running ?make install? with a different value of prefix from
> | the one used to build the program should /not/ recompile the
> | program.
Yes, they are a bit controversial in this point.
But imagine this: You're doing a cross compile. The host system will
need hardcoded paths in libraries (to be correct at run time), starting
with $prefix. The package needs other, previously installed libraries,
available below $DESTDIR/$prefix/lib.
Currently we don't handle this well. Wouldn't it be nice if you
specified at 'make' time (or 'configure' time, FWIW) both $prefix and
$DESTDIR, relinking at 'make install' time would be unnecessary in
this case? After all, you may not want or even be able to execute an
uninstalled program in the cross-compiling setup.
> > some make implementations won't override a set macro:
> > make install prefix=/tmp/dest
> > Instead, you'd have to
> > prefix=/tmp/dest make -e install
> Such `make' implementations are broken. The GNU Coding Standards
> don't explicitly mandate the use of GNU make, but neither do they
> demand that such broken behaviour should be accommodated; I've
> seen it stated elsewhere that, when constructing a GNU package, it
> is not unreasonable to expect GNU compatible `make' behaviour.
Broken or not: they are still in use. I remember one or two related bug
reports against Libtool in the last year.
Look Keith, I'm not even defending the GCS -- I don't want to, I have my
issues with them as well. All I am is trying to state a few facts and
give a few reasons. Neither am I trying to advertise Automake. Your
needs may be different from other people's needs.
> > which comes with its share of issues itself, if your environment
> > contains other surprises. This is not an issue with DESTDIR, as
> > it is not defined in Automake-created Makefiles.
Look: it does not _set_ DESTDIR, i.e., it does not contain
I did not say it does not _use_ $(DESTDIR).
> It was when I last looked at automake, along with dozens
> of other redundant constructs, particularly several layers of `make'
> targets serving only to obfuscate the build process into complete
> incomprehensibility, through redirection to multiple levels of
> redirected targets, each serving no apparently useful purpose.
This is unspecific criticism. If you can state a specific item you
think is not necessary or can be done in a better way, or you don't
understand, then by all means, please go ahead and describe it, so
it can be fixed. Otherwise, I'll just ignore this -- nontechnical
discussion about this is a mere waste of time to me.
Surely for GNU make the created Makefiles could be simpler; AFAIR
the idea of optionally creating GNU make-specific Makefiles has been
considered but abandoned/not yet pursued due to increased complexity
and lack of time/motivation. OTOH, as a user I rarely need to look at
the created Makefiles.
> > Surely the set of variables over which Automake claims
> > responsibility is not easily recognizable (i.e., without reading
> > the manual).
> This is precisely the problem with automake; it is yet another tool
> to learn, and so far I remain unconvinced that it delivers sufficient
> benefit to justify the expenditure of time to learn it.
Fair enough. Nobody is trying to persuade you. If you've been fine
without it, by all means don't change.
> > Also it may be of help to note that much of what Automake does is
> > realize the requirements listed in the GNU Coding Standards, however
> > debatable or not they may be.
> And I can write a simpler, more comprehensible Makefile, without all
> of the automake verbiage, which will also conform to the GNU Coding
Fair enough as well. Do you use a similarly elaborate dependency
tracking mechanism, by the way?