Re: Automake violations of the gnu coding conventions

[Ralf Wildenhues]

* K. Richard Pixley wrote on Tue, Jun 19, 2007 at 06:20:39PM CEST:
> Ralf Wildenhues wrote:
> >  
> >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.

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.

I'm trying to turn this discussion into a productive one.

> 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.

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.

Whether and how Automake should be changed to also work better for
non-release ways (thus not covered by 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.

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.

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>.

> In effect, you're saying that it's ok for automake to violate the GNU
> coding conventions because... well, I can't see why.

No.  I'm stating there is no GCS violation unless I can see and
understand it.

> >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.

Are you saying that you have worked on Automake?

> 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.

Cheers,
Ralf