Re: Automake violations of the gnu coding conventions

[K. Richard Pixley]

Bob Proulx wrote:
> 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.
>   
But that's my point.  With the defaults as they are now there are many 
"normal" cases where automake is required.  Since it should not be, I 
submit that automake is broken in that it violates the gnu standard.
> Obviously from the questions you are asking you are experiencing a
> specific problem.  Could you share some details?
I have already done so.  The actual use case is somewhat more involved 
than is necessary to explain the problem.

However, do the following.  Untar your favorite AM configured program.  
Remove automake from your system.  Do "find . -name Makefile.am | xargs 
touch", then configure, make all check install as usual.  You'll see the 
problem immediately.
> > 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.
You are correct in that it is only needed in this case.  However, there 
are many other cases where it is being regenerated because there are 
many other cases where the file time stamps are adjusted, lost, or 
randomized.
> I don't see a good alternative in that case.
The GNU coding convention would seem to suggest that the right answer is 
to decline to rebuild Makefile.in automatically.  it's ok if there's a 
"make automake" or some such, but you can't simply let Makefile depend 
on Makefile.in depend on Makefile.am because doing so requires the user 
to have automake installed in order to build in some cases.
> If
> the automake source file is modified then presumably the person doing
> the modification wants the change and then automake would be required.
>   
Not necessarily.  There are a number of cases, (cvs), where Makefile.am 
has a more recent modification date that Makefile.in.  It hasn't 
actually been modified, but you can't tell that solely from file time 
stamps.
> 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.
>   
Only if they were actually changing the file.  If they were, say, "cp 
-r"'ing a tree from their neighbor, they aren't necessarily developing, 
and yet they are suddenly forced to have automake installed.
> > 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.
This doesn't solve the problem I"m talking about.  The rule I'm 
complaining about is, in part:

$(srcdir)/Makefile.in: Makefile.am
   blah, blah, blah

This rule attempts to write to the, (potentially read-only), source 
directory and is, I claim, therefor broken.

>   Example:
>
>   mkdir /tmp/project
>   cd /tmp/project
>   /media/cdrom/project/configure
>
> That is an example build from a read-only source directory.
>   
Which will fail when make tries to run automake to regenerate 
Makefile.in, since that directory is read-only.
> > 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
>   
This will also break given the current set of rules.  You won't be able 
to build without automake, and even if automake is present, you'll still 
be hosed if the source directory is read-only.
> 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.
>   
"Munged" here is a very subjective perspective.  "Cp -r" will create a 
source tree that can't be built using the current rules.  So will 
checking the tree into, say, cvs or perforce and then checking it out.
> 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.
I've already done so, but here's  a repeat of most of those problems.

BTW, this argument isn't new.  I had the same discussion with automake 
and configure folks 15 years ago.  And this stuff is still broken.

--rich