Benoit Sigoure wrote:
Quoting "K. Richard Pixley" <[EMAIL PROTECTED]>:
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
