Re: libposix - is it done yet?

[Gary V. Vaughan]

On 11 Oct 2010, at 04:45, Bruce Korb wrote:
> On 10/10/10 13:59, Bruno Haible wrote:
>> Bruce Korb wrote:
>>>> IMO the inclusion guards of the headers need to be transformed
>>> IMO, I don't know that.  If a confused program winds up including
>>> both, then you'll have duplicate definitions.  Theoretically,
>>> the contents of libposix and what you get from gnulib would be
>>> the same.
>> 
>> No, they are different because the @GNULIB_XXX@ macros expand to different
>> values. For example, in string.in.h there are @GNULIB_XXX@ that are 0 in
>> libposix and may be 1 in other packages.
> 
> and when one ``#include <string.h>'', which should they be expecting?
> I am sure it has been thought out, but allowing both sure sounds like
> an invitation to a conflict should both wind up in the same compilation
> unit.....I will unique-ify them, but I think there be trouble there.

Unique-ifying is the correct solution.  As with any other header, when
a source file says #include <string.h>, they should expect to get the
first string.h along the compiler include path... gnulib headers do make
use of #include_next on machines that support it, which is another good
reason to make sure that if you build a package that uses libposix, you
shouldn't also have another gnulib string.h inserted into your package
source tree (especially because the package header directory will be
earlier in the compiler include path).

>>> Then it may as well be:
>>> 
>>>  libposix_la_LDFLAGS += -version-info 0:0:0
>>> 
>>> because the only other rational choice is going to be a version
>>> that changes daily whether or not there are changes to the
>>> interface.  Just hard code to 0:0:0 -- with comments about why.
>> 
>> No, this is wrong. If you hardcode 0:0:0, the slightest backward incompatible
>> change will break existing linked programs.
> 
> However, since folks fixing the modules are highly unlikely
> to be thinking about miniscule perturbations of libposix
> interfaces, then you wind up with these choices:
> 
> 1. immutable, with the noted problem
> 2. Use version $YEAR$MONTH$DAY:0:0 necessitating a recompile
>   of everything that uses it with every new libposix installation.
>   Probably not good either.
> 3. People (or someone) takes responsibility for twiddling the LTV_*
>   values for every change to the library.  Who would that be?

Whoever co-ordinates the official stable libposix releases.

> I certainly agree that #3 is best.  I just don't see how it'd work well.
> I think #2 would make it unusable.  There is a fourth possibility:
> 
> 4. Write some comprehensive interface measurement tool that auto-bumped
>   the revision number and triggered a warning for a human being to
>   check for possible interface incompatibilities.
> 
> That's beyond the scope of what I've got time for.

Managing library versioning is a difficult problem for any package.  Such
a tool *would* be very useful for any package that ships non-trivial
libtool libraries.  But it's a whole project unto itself as you say.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part