[Gc] Maintainers attention: libatomic_ops
matthias.andree at gmx.de
Wed Sep 30 08:29:36 PDT 2009
Am 30.09.2009, 17:02 Uhr, schrieb Henning Makholm <makholm at octoshape.com>:
>> Show the GC-related ones.
>> Show the GC-related ones.
>> Show the GC-related examples.
> So you're arguing for omitting the possibility of testing
> things until they have been conclusively shown to fail, not
> only in general but in the very same project?
You've been arguing that the developer/maintainer should be annoyed just
because you've heard rumors that a newer automake version might break
somewhere, and, let me exaggerate, if some voodoo priest rapes and kills a
cat and throws it backward over his left shoulder at full moon and
performs a magic dance.
My first point is that you don't forfeit testing by removing generated
auto* stuff from CVS, you can (and should) still do release tests with
release candidate tarballs.
My other point is that using reproducable ways to generate auto* stuff
from checkouts (which will usually be just "autoreconf -i" perhaps
combined with -f, -s, -v, or a combination thereof) is usually sufficient,
i. e. I have (from several auto* using projects) yet to see projects where
upgrading automake or autoconf breaks the build or code.
> That's not what testing is for.
Yes but you don't want to focus on auto*, that's not what outsourcing and
reuse are for. auto* is there so you can focus on your development and
auto* will handle the platform/OS differences.
> Perhaps so. That's why it is important for it to be possible to
> FIND OUT that something has been done wrong.
Yes, but you don't do that through testing of auto* versions that have
been discontinued by their maintainers years ago and have been unsupported
In case of failure your only resort is introducing version-specific hacks
to work around the auto* bug -- the very dependencies that you now argue
are the reason why auto* generated files should remain in CVS.
Meaning that your argument runs in a cycle and is trying to support itself.
>> "make distcheck" by the release manager will do, providing that "make
>> check" is reasonably complete to exercise the relevant parts.
> No it won't, not if the things that fail to work are for platforms that
> the release manager do not have available for testing.
You can't claim platforms supported unless you have a coworker who will do
the necessary porting, and that coworker will need to do the release
candidate testing anyways.
>> You can always distribute the tarballs generated that way to testers
>> on other platforms and achieve the same kind of testing as you do
> Testing that is delayed until late in the release cycle is not "the same
> kind of testing" as allowing the one who develops a patch to test it
> WHILE HE DEVELOPS IT, with the same autotools version that will
> eventually be used to generate a tarball.
Which will usually boil down to build and test suite failures which are
>> without a need to pollute CVS with autoreconf-generated files.
> I fail to see how it is relevant to this discussion whether the generated
> files are in CVS or not.
That was Hans's point of cluttered "cvs diff"... if you could be bothered
to reread his post in this thread.
> 1) If (as I argue) all developers agree on which autotools versions are
> be used for development in the project -- then having the generated
> in CVS is generally more trouble than it is worth, mostly because
> of generated files from CVS are likely to confuse the regeneration
You'll necessarily have to settle for the only supported version, i. e.
latest and greatest, which is usually hard to agree on.
> 2) If (as I argue against) each developer chooses his own favorite
> of autotools independently and then blindly checks in build-related
> that has been tested only on that version, in the hope that it will
> work on whatever (older, newer, who knows) the release manager uses
> -- then having the generated files in CVS is *definitely* more
> than it is worth, because (in addition to bloat) whether things work
> not with a fresh checkout will depend on who last did a commit.
The whole point of auto* is to decouple the built software both from the
differences between the development machines and between the
targeted/supported systems. If you're changing the build system all the
time you should really reconsider what your project is about: its stated
purpose or exercising auto* versions or working around auto* bugs fixed in
newer auto* releases just because it improves testing and prevents
If GC's purpose is to exercise and test the build toolchain and go
paranoid about avoiding auto* flaws just to substantiate your claims about
auto* breakage and forward incompatibility, you're right to all agree on a
particular version, but in any other setting the agreement on a ">=
version" is better suited, and for reasons you already gave, are a very
good reason to kill all generated files.
And I think I'll stop arguing here. I'm not a regular GC contributor, so I
could hardly care less about the pains the GC developers are going to
inflict upon themselves by following FUD arguments and paranoia and
screwing their access to support of the build system.
For serious questions as to improving auto* stuff in the build system, I'd
be happy to help, time permitting.
More information about the Gc