Re: Automake violations of the gnu coding conventions

[Bob Proulx]

K. Richard Pixley wrote:
> I notice that automake is currently generating Makefiles that violate 
> the gnu coding conventions.

Hmm...  I don't think that automake violates the standards.  In the
normal case it is not required to have automake installed.  Someone
who is simply building from the generated Makefiles never needs to
have automake installed.  Only a developer who is modifying the
automake source files would need automake installed.

Obviously from the questions you are asking you are experiencing a
specific problem.  Could you share some details?  I would rather see
the problems you are experiencing addressed rather than see the
generated Makefiles crippled.  There is always AM_MAINTAINER_MODE but
I think the cure is many times worse than the disease.

Meanwhile, let me address some of your points.

> Specifically, it's generating rules for rebuilding "Makefile" from
> "Makefile.in" and "Makefile.in" from "Makefile.am" which requires
> automake.

Rebuilding the generated Makefile.in file is only needed if the source
file is modified.  I don't see a good alternative in that case.  If
the automake source file is modified then presumably the person doing
the modification wants the change and then automake would be required.
Anyone doing this would fall into the developer role and there is an
expectation that developers must have the appropriate tools available.
If you are not modifying the automake source files then automake is
not required.

> Also, in the past, there were coding standards that prohibited Makefiles 
> from writing into $(srcdir).  The problem here is that source code 
> directories might be read-only as comes from a cdrom, or from a shared 
> but not owned source directory, (perhaps on a network server).

Please use VPATH builds for read-only source directories.  Example:

  mkdir /tmp/project
  cd /tmp/project
  /media/cdrom/project/configure

That is an example build from a read-only source directory.

Note that 'make dist-check' simulates read-only source and is one
check that projects can build from a read-only source tree.

> Note that these problems are particularly troublesome when one uses a 
> file transfer method for copying or moving source trees that doesn't 
> necessarily retain last modification time stamps, like source code 
> control systems, "cp", etc.  In these cases, the source directory 
> becomes unbuildable.

When filestamps are munged then the simple action of touching all
files to the same timestamp is a good workaround.

  find . -type f -print0 | xargs -r0 touch -r configure.ac

Normally I would avoid munging timestamps of files.  However in the
case that they are already munged then I see no additional problem
with getting them all into a consistent state.

Again, I would appreciate it if you would describe the problem that
you are experiencing that has led you here with a complaint about
automake.

Bob