[Gc] Maintainers attention: libatomic_ops

Matthias Andree 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  
since.

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
>> today,
>
> 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  
quite obvious.

>> 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  
> to
>     be used for development in the project -- then having the generated  
> files
>     in CVS is generally more trouble than it is worth, mostly because  
> updates
>     of generated files from CVS are likely to confuse the regeneration  
> logic.

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  
> version
>     of autotools independently and then blindly checks in build-related  
> code
>     that has been tested only on that version, in the hope that it will  
> still
>     work on whatever (older, newer, who knows) the release manager uses
>     -- then having the generated files in CVS is *definitely* more  
> trouble
>     than it is worth, because (in addition to bloat) whether things work  
> or
>     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  
upgrades...

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.

-- 
Matthias Andree


More information about the Gc mailing list