[Gc] Maintainers attention: libatomic_ops

Henning Makholm makholm at octoshape.com
Wed Sep 30 09:10:08 PDT 2009


> 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 point is that restricting oneself to "release tests" is not enough.

The most important testing is the one the developer who originally wrote
the code does while he is writing the code. This testing needs to be
dependable, and for that it is essential that he tests it with the same
version of the language he is writing in as his code will eventually
be executing with.

> 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,

But the procedure you're arguing for DOES NOT result in reproducible
generation of auto* stuff. For that you need an agreement on which verion
to use.

> i. e. I have (from several auto* using projects) yet to see projects
> where upgrading automake or autoconf breaks the build or code.

If the developer happens to be using a newer auto* version than the one
who does releases, then we're not talking about an upgrade but a DOWNgrade
when the final build scripts are generated.

How can you be so sure that the developer will not unwittingly depend on
a feature in his version that did not yet exist in the version used by the
release manager?

>> 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.

Huh? Who said ANYTHING about "testing of auto* versions that have been
discontinued by their maintainers years ago"???

> 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.

Huh? I do not understand at all what it is you try to present as "my"
argument. I have not proposed any "reason why auto* generated files should
remain in CVS." That would be silly -- they shouldn't.

> 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.

But why should he have to wait until just before release before he can
test his porting work? It would be much more sane to set things up so he
can test the porting work, including the build stuff, as he goes along
porting.

>> 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.

Hans wrote:

     I suspect we should standardize on particular versions of the
     autotools to minimize gratuitous and voluminous output from cvs diff.

You replied:

     No, don't do that. You shouldn't ever need that,

The reason offered for standardizing versions (cvs diff) is a weak one,
but your contention that "you shouldn't ever need" to agree on which verion
to use implies that developers SHOULD strive to use as different versions as
possible, which is what I oppose.

>>  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,

Why? Older versions usually work fine as long as you don't need things
they do not support. They do not magically stop working because their
authors release a new version.

> 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...

Is this supposed to be somehow releated to something I've said?

> If GC's purpose is [strange strawman about finding bugs in auto*],
> you're right to all agree on a particular version, but in any other
> setting the agreement on a ">= version" is better suited,

So accoring to you, it is a good thing to

 1) Agree on "autotools version >= 12345"
 2) Therefore let one developer use autotools version 12349
 3) This developer changes stuff in the build system to make things
    work for the port he is maintaining. He tests his changes with
    autotools 12349, and they work fine. He commits them to CVS.
 4) Much later a tarball gets built with autotools 12346,
    and circulated for last-minute testing.
 5) Unfortunately some of the changes the developer made depended
    on features only present in autotools >= 12347.
 6) Only then does the developer get a chance to realize he made
    a mistake.

How can this POSSIBLY be an improvement over the developer discovering
in step (3) that his changes won't work?

--
Henning Makholm
Octoshape ApS



More information about the Gc mailing list