Re: libposix - is it done yet?

[Bruce Korb]

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.

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

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.

>>> 5) The libposix.m4 file should be rewritten from scratch to *not* use
>>> pkg-config and instead use the macros from the gnulib 'havelib' module.
>>> 6) On Solaris 8, with gcc, the files fnmatch.h, float.h, errno.h, stddef.h,
>>> stdbool.h, stdarg.h, sched.h get created after the library has been built,
>>> with invalid contents (#include_next without argument, and such). The 
>>> mistake
>>> is that you have included stddef.h in nobase_nodist_pkginclude_HEADERS,
>>> although STDDEF_H is empty on this platform.
>>
>> Yep, these are still hang-out items.  It isn't obvious to me how to load
>> the nobase_nodist_pkginclude_HEADERS macro
> 
> nobase_nodist_pkginclude_HEADERS = $(FNMATCH_H) $(FLOAT_H) $(STDDEF_H) ...

so the script must first determine the full list of headers
that might be provided, convert them to $(XXX_H) names and
stuff the list into the *_HEADERS thing.  Having looked
through the module sources, there is no clear way of
deriving the list of header macro names.  Sure, I can figure
it out by hand, but that won't cope with future changes.  It
needs to be derivable.  Grepping out ".h" files from the
Files: section does not work -- file names get converted
during the sedding.  The Include: section won't work,
there's too much clutter and there really isn't a way to
figure out which header gets glued into which $(XXX) macro.
I guess I could do a trial build and grep it out of the
substitution script (config.status).  That script would have
to ship with the project and is harder to do anyway.  I
don't think so.  It feels really, really wrong.  So, I'm
back to uninstalling broken headers at post-install time,
unless you can tell me how to derive that list of
$(FNMATCH_H) $(FLOAT_H) $(STDDEF_H) ... names.

Thank you again for your help and feedback!

Regards, Bruce