Re: Automake violations of the gnu coding conventions

[K. Richard Pixley]

Ralf Wildenhues wrote:
> > What you seem to be saying is that anything that doesn't work with 
> > automake is broken by definition.
> >     
> No.  What I'm asking for is a step-by-step reproducible example of the
> breakage you are encountering, including the make implementation that
> was used, and all other details I need to reproduce it.  A fundamental
> thing that one can expect from a bug reporter.
>   
This is not a bug report.  It's a query about whether it might be time 
to change this policy of automake.  I'm sure that automake is 
functioning as designed.  And I'm calling that design into question.

I've already listed the means for reproducing the problem several 
times.  I can do so again, but the argument so far has been "we don't 
support that".  And yes, I understand that automake doesn't support this 
use case right now.  However, it has in the past, the GNU coding 
standards do, and there's a need for supporting this use case.  My query 
is entirely about whether it might be time to support this use case now.

If the answer is "no, we don't want to support that", that's fine.
> No.  The GCS speaks about releases and release tarballs.  And my claim
> is that Automake-generated Makefiles do not violate the GCS in this
> point.  You argue that but so far do not bring proof.
>   
I've shown you a use case.  I've shown you a section of the GCS.  I've 
shown you a situation in which automake does not match the GCS.  What 
more proof would you like?
> Whether and how Automake should be changed to also work better for
> non-release ways (thus not covered by GCS)
I think this is debatable.  You seem to be thinking that the entire GCS 
must be taken as a whole or that none of it is valid.  That if, say, the 
package isn't aggregated into a tarball, then there's no point in 
keeping with the indentation standards, or to the memory use strategies.

This isn't my understanding of it's intent or it's history, (and I 
helped develop it).  My understanding is that each of the sections of 
the GNU Coding Standards are intended to stand on their own, separately, 
and in isolation from each other as well as in concert.  They are 
intended to offer recommendations for all coding projects, especially 
free ones, and most especially those intended specifically for use in 
the GNU project.

I believe that the memory use strategies are useful, even if a package 
doesn't come in a tarball and doesn't have a configure script.  And I 
also believe that it's useful if a package can be built with only 
standard tools, even if it was transmitted in a form which reassigned 
file modification times.  The fact that some instantiation of the source 
code lacks the file modification times of the original release is not 
justification for discarding any of the rest of the GCS.
>  of obtaining packages is
> certainly debatable.  But there is also an argument against it:
>
> The Makefile.in rebuilding rules help developers not forget to
> regenerate those files.  They have been put in place for this reason.
> They do certainly reflect the notion that non-release users of packages
> are likely to be developers that ought to have rebuilding tools in
> place.
>   
I am aware of this value and this goal.  I'm contesting it.  I'm 
questioning whether this goal is really of such value that it merits 
abandoning a number of use cases which are covered by the GCS.
> But before we explore this argument further:
>
> There is a related point which has not been said so far at all: all
> non-ancient versions of Automake employ a script called 'missing' to
> make up for tools that are missing at 'make' time.  This script should
> also help for the case that Makefile.in is out of date but automake-x.y
> does not exist on your system.  It should make things work regardless of
> AM_MAINTAINER_MODE.  If you get a failure, then I would like to see it
> exactly in order to be able to judge whether the package or Automake has
> a bug perchance.  So we're back to square 1: show me an example.
>   
I don't understand how "missing" addresses this situation.  And I 
haven't ever seen it work in this situation.  While I have seen the 
situation arise numerous times.

Are you suggesting that the "missing" script somehow stands in for and 
does the job of automake?
> If we get to an example that cannot be fixed, then (and only then) let's
> explore other solutions like the one you have outlined in
> <http://thread.gmane.org/gmane.comp.sysutils.automake.general/8356/focus=8373>.
>   
I believe that I have offered my use case three times now.  But here's a 
fourth.

Pick a package that uses automake.  Download the tarball.  Unpack.  
Remove automake from your system.

At this point we need to scramble the file time stamps.  You can do this 
in any number of ways.  The easiest, albeit artificial method, is to 
simply touch Makefile.am.  However, you can accomplish the same thing by 
storing the code into cvs, or subversion, or perforce, or any of a 
number of other source code control systems.  You can also do it by 
moving the unpacked code, perhaps using rsync, or scp, or http, or even 
the venerable old insecure ftp.

Then configure and attempt to build the package as usual.
> Are you saying that you have worked on Automake?
>   
Of course.  I've also worked on autoconf.  I wrote Cygnus configure, the 
Cygnus makefile system, and the paper coining the phrase "Canadian 
Cross".  And I set up and managed source code control and the packaging 
system of the first commercial binary release of the GNU toolchain.  I'm 
not sure how that's relevant to this discussion, though.
> > 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.
> >     
> What?  The conversion from Makefile.in to Makefile is typically part of
> the configure process (config.status to be precise), so user's choice.
You've lost me here.  A conditional that takes place at automake time 
isn't useful to a typical builder who doesn't have access to (the right 
version of) automake.  And makefile conditionals in v7 make aren't 
trivial, tending to require an extra level of recursion.

What level of conditional are you talking about?

--rich