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], [bug-gnu...@gnu.org])
>
> 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 (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part
