Re: FYI: use api version

[Tom Tromey]

>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

adl> Presently it's not that bad: branch-real-1-5 uses 1.5.1a, so
adl> including anything before the second dot in the API version
adl> doesn't appear to conflict.

Thanks.

adl> 1) change the API version for any version released from HEAD,
adl>    including prereleases, because one can't guaranty something he
adl>    is unable to check (API compatibility).

I don't think of it necessarily as a guarantee (though I have used
that word).  I think of it more as a criteria for determining what is
a bug.  An API incompatibility from 1.5 -> 1.5.1 would be a bug, just
like certain failures with a vendor make are bugs.

adl> 2) keep the same API version for any bug fix release, but be
adl>    very picky about what goes on these branches.
adl> 3) document what is part of the API, and what isn't.  (That's
adl>    probably the hardest.)

I agree with these.

adl> For instance, the manual says that if `bin_PROGRAMS = maude' you
adl> can use `maude_LDFLAGS = mumble' (who is maude, btw?), but it
adl> doesn't say whether Automake reserves the whole `*_LDFLAGS'
adl> namespace for this purpose or not.

Maude is my dog.

adl> (By `orphan' I mean there is no target associated to the
adl> variable.  I find Automake's wording of `unused' to be
adl> confusing, because in these test cases the variables *are*
adl> used.)

Yeah.

I agree partly this is a documentation problem.  But it is also partly
that I've made poor choices (and sometimes good choices :-) during
automake's evolution.  The "unused variable" error might be one or the
other.  It was introduced because we found people would have a typo in
some auxiliary variable (e.g., "maube_LDFLAGS"), causing obscure
failures.  (Sometimes these failures can be hard to debug, for
instance if the variable in question only has a value on an unusual
platform or in an unusual situation.)

In this situation, and perhaps in many of the ambiguous cases, it
makes sense for us to first think about what we want moving forward.
Then we can design, document, and implement the desired approach.  On
the "stable" branches we will be conservative, perhaps removing things
as you say.  For instance we could even consider disabling certain
error messages if it is expedient.

Tom