Re: Automake violations of the gnu coding conventions

[K. Richard Pixley]

Bob Proulx wrote:
> Are we talking about one of your own projects?  Or are we talking
> about other projects that you are trying to build?
>   
Projects that I'm trying to build.  Hundreds of them.  Projects that 
won't be fixed in their current incarnations even if we correct automake 
now.  It'll take years, maybe decades for this change to propagate into 
all of the packages that suffer from this problem today.  I know that.  
And I'm willing to help with that effort if it's deemed appropriate to 
return to the GNU coding standards, (which were formulated with these 
use cases in mind).

I will be solving this problem somehow.  The real question is whether we 
can cooperate in such a way that we solve it once now and everyone can 
benefit, or whether I'm going to solve it today for this company, 
tomorrow for some other company, and next week for yet another company.
> K. Richard Pixley wrote:
>   
> > Bob Proulx wrote:
> >     
> > > 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.
> >     
>
> But the cases that you have described so far are not normal cases.
> They all entail doing something that can be reasonably avoided.
>   
That's really not a helpful or useful attitude.  I can also reasonably 
avoid any of these problems by avoiding any program that uses automake.  
Avoiding the problem isn't really solving it.

Of course these aren't the common, current automake use cases.  Automake 
can't solve these cases now and thus these cases can't be covered.  What 
I'm talking about is extending automake to cover the cases that used to 
be possible prior to automake.
> > > 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.
> >     
> Reading your mail carefully I note you say that 'cp' does not retain
> file timestamps.  Instead of using 'cp -r' use 'cp -a' to preserve the
> timestamps.  An easy problem to avoid.  Or "correct" them later by
> updating all of the timestamps.  Either works.
>   
Fine, then.  rsync.  Or cvs, or subversion, or perforce.  There are many 
situations where source can be transmitted which do not preserve file 
modification times.  And I really don't think that the rest of the world 
should be modified solely to support this deficit of automake.  
Especially not when the solution is so simple - just follow the gnu 
coding standards.
> If someone is trying to build from source control then they have
> assumed the role of a developer.
No, I'm sorry, but that's not necessarily true.  A developer of foo is 
not necessarily a developer of bar.  They may be capable of becoming 
one, but that's not how most organizations prefer to allocate their talent.
> Developers are expected to have the
> required development tools available.  Almost certainly in the case of
> checking out pristine source from version control many developer tools
> will be needed for most projects.  This goes beyond automake and
> includes gettext, flex, bison, gperf, texinfo, etc.
Actually, it's not.  At this point in time, to build a variety of free 
software, (say, debian), requires multiple versions of multiple autofoo 
tools.

Consider the use case where a third party is both collecting released 
code as well as monitoring it locally.  There may or may not be local 
changes to that code prior to further releases.  And it may or may not 
be possible to regenerate the generated files what with ancient code, 
version incompatibilities between the autofoo packages, etc.  In this 
case it is necessary to track both the original source as well as the 
generated files.  And to return the generated files back to the GNU 
coding standards in order to keep them building.

A much more efficient approach involves using the generated files as 
they were released.  But unfortunately, this isn't really feasible with 
the Makefile -> Makefile.in -> Makefile.am rules as they come now.

--rich