Ralf Wildenhues wrote:
Hello Richard,
* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 05:18:27AM CEST:
AM_MAINTAINER_MODE is good to know about, thank you. But it doesn't really
solve the problem for users. Now if generated makefiles could have those
rules turned off using a command line and/or environment variable, that
might be useful. Then we could build packages without automake, so long as
we had AM_MAINTAINER_MODE=no in our environment. But again, I'd argue that
it was the maintainers who should set the variable and that the default
should be no dependency on automake.
Others have already argued it, but once again: if you have an extracted
tarball of a package that uses Automake, and building it causes automake
(or autoconf, or aclocal) to be run, then there very very likely a bug
in one of:
- the package's Makefile.am files
- the way packaging was done
- or the time stamps were messed up along the way.
This holds independently of the whole AM_MAINTAINER_MODE thingy. And if
all steps are done right, then the basis of this whole thread becomes a
non-issue.
Well, sure. But the essence of the problem here is an incompatibility.
The question is whether automake is willing to step up to the GNU coding
conventions, which solve several of these incompatibilities, or whether
automake is going to continue to declare that it is the center of the
world and that any process which breaks automake is flawed simply by
definition.
I claim that automake is flawed because these problems were solved long
before automake and their resolutions were encoded into the GNU coding
conventions. Following the GNU coding conventions would solve these
incompatibility problems in many of the current cases of incompatibility.
There is no way that Automake can avoid relying on time stamps, as it's
'make' that relies on them, and Automake relies on 'make'.
Actually, there is.
There's no need for automake to include the full chain of Makefile
depends on Makefile.in depends on Makefile.am by default. Drop that
last dependency from the default dependency topological sort. Then
Makefile depends only on Makefile.in, which can be regenerated using
configure, which only requires sh.
You can then invent a separate dependency tree, say, "make automake" or
"make regen" which includes rules for generating Makefile.in from
Makefile.am, but doesn't use standard dependencies to do so. If
regenerating Makefile.in from Makefile.am were done unconditionally,
perhaps as a side effect of a .PHONY rule, then the problem goes away.
The difference in use case is that automake developers would then need
to explicitly request "make regen" in order to force rebuilds of
Makefile.in's from Makefile.am's. But the benefit is that automake
generated makefiles would once again adhere to the GNU coding standards,
builds from read-only source directories would return to functioning as
they do in non-automake GNU packages, and the time stamping problem I've
described also becomes a non-issue for packages using automake.
If you have a counter example to above, please show how to reproduce it.
Thank you.
What you seem to be saying is that anything that doesn't work with
automake is broken by definition. That's a very automake centered
perspective which doesn't really correspond to real world usage today.
It also violates the GNU coding standards which were specifically
designed to support the use cases that I've already described. In
effect, you're saying that it's ok for automake to violate the GNU
coding conventions because... well, I can't see why. Is it really the
case that you want to exclude a fair number of use cases solely in order
to create a tiny, confusing convenience for automake developers?
Of course, you can't do the conditional thing easily without resorting to
GNU make extensions, so we'd likely lose the ability to build with a v7
make program.
Automake conditionals are implemented in a way that they work with a v7
make program. They do not use a GNU make extension. The limitation is
that the decision is done at the time the conversion from Makefile.in to
Makefile is done, rather than only at 'make' invocation time.
Lol. Yes, thank you. I'm well aware. I was part of the group of
people who originally made those decisions back in the early '90's.
What I'm saying is that a conditional that takes place at that time
isn't useful to a typical builder who does not have version X.Y of
automake handy. He can't use that conditional.
My argument is that it is automake developers who should be forced to
take extra action, not typical builders. And I'm exploring
alternatives. One alternative might be to it might be to make that
conditional decision later, after the Makefile.am -> Makefile.in
conversion. Doing so would be clumsey in v7 and this functionality
isn't, imo, worth losing v7 compatibility. Hence, I'm discarding the
possibility of a later conditional and returning to my original thesis.
It is automake developers, people who are in a position to exploit an
automake time conditional who should be encouraged to take the extra
action. Typical builders cannot do so. They aren't in a position to do so.
--rich