Re: Automake violations of the gnu coding conventions

[K. Richard Pixley]

Benoit Sigoure wrote:
> Quoting "K. Richard Pixley" <address@hidden>:
> > Bob Proulx wrote:
> > > 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.
>
> You are right and that's exactly why developers of foo should not 
> attempt to use bar from {CVS,SVN,Perforce,...}.  They should use a 
> {pre-,}release tarball that has been produced by the developers of bar 
> with, say, make distcheck.
>
> If you are running into this sort of problem I think it is most likely 
> due to your unconventional usage of versionned sources.
>
> By the way, if you are stuck with a read only source tree, you can 
> still cp -r it to $TMPDIR and then fix the timestamp as it has already 
> been said.  And then ask the developers of bar to provide you with a 
> tarball :)
This is actually an extremely common and conventional usage of versioned 
sources.

And the solutions you've suggested make sense for one-off, one-time 
solutions, but don't scale very well.  When we're talking about hundreds 
of packages across hundreds of developers, we've just changed a build 
process of minute or hours into one of days or weeks.  And that's not a 
practical approach.

A more expedient solution would be to eliminate automake or to branch 
automake, fix the problem, and release the corrected version to the 
world so that other people who suffer from the same problems can benefit 
from our work.

I'm here now raising the issue in order to find out if there's some way 
we can cooperate on the work to find a solution that works for a wider 
audience that the solution automake uses now.  But it sounds as though 
I'm hearing that the current automake development group isn't interested 
in that sort of cooperation.

Is this really the consensus?  That continuing to violate the GNU coding 
standards is sufficiently important that it's worth alienating several 
classes of use conditions?  If so, then I'll look into other options.

--rich