Re: installable gnulib library

[Gary V. Vaughan]

On 10 Oct 2010, at 22:00, Bruce Korb wrote:
> Hi Gary,

Hey Bruce!

> On 10/10/10 02:14, Gary V. Vaughan wrote:
>> I think your script is *much* more complicated than it needs to be.
> 
> Of course it is.  To properly understand 150+ lines of usage text
> one needs to read the source and understand the intimate details
> of libtool and autoconf.  I keep meaning to, but life gets in the way.

Are you implying that libtool is complicated? ;)

>> It occurs to me also, that when another gnulib using project (that relies
>> on non-libposix modules) wants to minimise it's configury by requiring
>> libposix, gnulib-tool will need an --avoid-posix option or similar.....
> 
> That, or some mechanics for saying, "module X represents modules Y, Z, ..."
> whereby libposix says it represents the posix module list.  This would
> minimize the burden on gnulib clients (developers) to remember one more
> thing.  I like reducing that burden, but it _is_ likely harder... :)

I can't think of a way to make this completely transparent.  At some point
you have to tell gnulib-tool that you are using an installed libposix in
place of some selection of gnulib modules, so you might as well take the
path of least resistance, and implement --avoid-posix rather than some
complex solution.

>> ## configure.ac:
>> 
>> AC_INIT([libposix], [20101010], address@hidden)
> 
> The version will need to be computed :)

Did I get the calculation wrong?  I am UTC+8, so it was right for me at the
time I wrote it ;)

But seriously, gnulib already provides the tools to do this (git-version-gen
and .tarball-verion), so let's use the existing rather than invent something
new.

>> 2. posix-modules vs alloca
>> --------------------------
>> The modules specified by posix-modules require an LTALLOCA definition, per
>> 'libposix/Makefile.am:35: @LTALLOCA@ used but `LTALLOCA' is undefined'.
>> So I had to add the alloca module to the gnulib-tool invocation in bootstrap 
>> above.
> 
> Yep, that's why this *HAS* to be tested all over the place.
> That module is not needed when building on Linux....

Agreed.  And why a libposix tarball should ship with the unit tests for all the
modules it uses.

>> 4. pt_chown module
>> ------------------
>> gnulib/modules/pt_chown hardcodes libgnu.a, so I had to edit the gnulib
>> generated libposix/Makefile.am in libposix to refer to libposix.la instead.
> 
> If it is a nuisance to fix, some script must create the correct "configure.ac"
> anyway, so it may as well hack up libposix/Makefile.am if it is easier.
> It's a one liner:
>    sed -i "s/libgnu.a/${TARNAME}.la/" ${TARNAME}/Makefile.am
> But actually, it has to be sedded or gnulib-tool must be augmented anyway.
> Neither the library itself nor the header files are installed.
> It would be useful to do that, too.  That is actually the bulk of the
> functionality of my script (aside from infrastructure overhead).

*Almost* agreed.  Except that I think that sed belongs in gnulib-tool, and
should fire automatically when the gnulib Makefile.am is generated.  libposix
is not the only client of pt_chown.

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

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