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. > > 2) The library should use libtool versioning: > > > > # Libtool's library version information for libposix. > > # See the libtool documentation, section "Library interface versions". > > LTV_CURRENT=0 > > LTV_REVISION=0 > > LTV_AGE=0 > > libposix_la_LDFLAGS += -version-info > > $(LTV_CURRENT):$(LTV_REVISION):$(LTV_AGE) > > 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. > > 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) ... Bruno
