automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake violations of the gnu coding conventions


From: K. Richard Pixley
Subject: Re: Automake violations of the gnu coding conventions
Date: Tue, 19 Jun 2007 09:20:39 -0700
User-agent: Thunderbird 2.0.0.4 (Macintosh/20070604)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]