[Gc] Maintainers attention: libatomic_ops

Matthias Andree matthias.andree at gmx.de
Wed Sep 30 07:32:56 PDT 2009

Am 30.09.2009, 16:01 Uhr, schrieb Henning Makholm <makholm at octoshape.com>:

>> I have yet to see real-world issues of this that aren't caused by misuse
>> of the auto* stuff such as incomplete autogen.sh scripts or use of
>> autoconf 2.13 compatibility cruft with 2.50+ versions (which have been
>> around for nearly a decade now).
> Blaming the problems on "misuse" does not change the fact that they  
> happen.

Show the GC-related ones.

Sorry for the pointed sarcasm, but you're free to oppose any changes to  
address maintainer issues just because it might break something. You may  
want to consider stopping any changes to the C libraries, too, just  
because platform specific code you cannot test breaks somewhere else  
through apparently unrelated changes.

> I don't know about particular version numbers, but it is definitely not
> unheard-of that the strange magic you have to use to beat automake  
> version N into creating the makefile you need will suddenly and sliently  
> stop
> working for automake version N+1, and vice versa.

This is vague, unsubstantiated FUD messaging.

There is no strange magic required to make automake work as advertised, it  
just takes reading the documentation and fixing the warnings if you goof  
up, just as in any other programming language as well. I need to put the  
"just" in relation, of course it takes a bit of practice and experience,  
too, just as it would for C, C++, Shell or other programming languages. It  
doesn't magically work, computers aren't stupid, but really stupid,  
without any trace of common sense.

> Feel free to call this "misuse", but that does not change the fact that
> such problems do happen in the real world.

Show the GC-related ones.

>> refer to incomplete or misordered rebuilds of the auto* stuff, and
>> usually also be fixed through autoreconf -ivf (add -s if you like).
> No, what I'm talkin about is code that works with one version of the
> tools and fails to work with another version of the tools, because  
> something it depended on had changed in the mean time.

If your code depends on the version of the build tools beyond requiring a  
minimum version for a certain feature, you're doing something wrong.

Show the GC-related examples.

>>> The code tested for each platform should be same code that eventually
>> > ships.
>> "Code tested" would be GC code, not the build surroundings
> Wrong -- build scripts also need to be tested. It will not do to ship a
> tarball with nonfunctional build scripts (because the auto* inputs were
> never tested against the autotools version that generated the build
> scripts from them).

"make distcheck" by the release manager will do, providing that "make  
check" is reasonably complete to exercise the relevant parts. 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, without a  
need to pollute CVS with autoreconf-generated files.

Matthias Andree

More information about the Gc mailing list