Re: installable gnulib library

[Bruce Korb]

Hi Bruno,

On 10/10/10 07:35, Bruno Haible wrote:
> Since creating a separate git repository is a lot of administrative work,
> I would suggest that you (Bruce + Gary) create a subdirectory in gnulib,

Since it is completely tied to gnulib, it is also appropriate.

Also, I tried.  Can you please fix access?

$ git push
fatal: The remote end hung up unexpectedly

> called 'libposix', with files such as
>   configure.ac
>   Makefile.am
>   version.in.h
>   version.c
>   README
>   libposix.m4
>   autogen.sh

I've occasionally objected to this name since Gnome started using it.
It is my project's name.  "bootstrap", please.

> Hmm. That's a good point. But often the projects (especially coreutils)
> need the newest stuff from gnulib, and a libposix.so that is 6 months old
> will cover maybe 80% but not 100% of what coreutils wants.
> 
> So I'd see that coreutils continues to use gnulib like it does now.
> 
> But for other packages, which add libposix to their required dependencies,
> such an option would be useful. Should I implement it? Other thoughts about 
> it?

As mentioned in my email from so many minutes ago, it ought to be
covered by "libposix is a sentinel for the following modules ..."
It would mean that either coreutils continues to use gnulib like it
does now, or coreutils would always be requiring a very recent libposix.
But it is just one project anyway.  The real deal is the gazillions
of projects that currently run through all the gnulib tests plus the
likely many gazillion more that don't use gnulib because of the hassle.

> What about the unit tests of gnulib modules, when a package is using an 
> installed
> libposix?

The unit testing of libposix should be done before libposix is installed.
Client projects should not need 'em.

> In a package that is itself called 'libposix', a subdirectory 'libposix'
> is confusing. I would suggest --source-base=lib or --source-base=.

I'll change it to "lib".

>> ## Makefile.am:
>>
>> ACLOCAL_AMFLAGS = -I m4
>> SUBDIRS = libposix tests
> 
> Ahem, there are two things missing here:

:-D

>> ## configure.ac:
>>
>> AC_INIT([libposix], [20101010], address@hidden)
>> AC_CONFIG_HEADERS([config.h])
>> AC_CONFIG_FILES([Makefile libposix/Makefile tests/Makefile])
>> AC_CONFIG_AUX_DIR([build-aux])
>> AC_CONFIG_MACRO_DIR([m4])
>> AM_INIT_AUTOMAKE([foreign])
>> LT_INIT
>> AC_PROG_CC
gl_USE_SYSTEM_EXTENSIONS
>> gl_EARLY
>> AM_PROG_CC_C_O
>> gl_INIT
>> AC_OUTPUT
> 
> Yes, this is a good start.

I'll jigger "bootstrap" to fiddle the version.
I've never heard an answer to my question, "is it too late to use
a dotted version?"  i.e. 2010.10.08 vs. 20101008
Much more readable and, actually, more easily dealt with by
a few (broken?) tools that expect at least one dot.

>> 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.
> 
> Yes, this seems unavoidable. I don't see how a program's LDADD could refer to
> the library; what kind of syntax in the module description file would you
> suggest for this?

First, there is the funny new syntax for this one problem, then there is
the hassle of implementing it all to avoid a single line of sed text.
I recommend just fixing it with the bootstrap script.

> The common way to get rid of these warnings is to insert an invocation of
> gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.

Could you explicitly define "appropriate place" in the sample above? :)
I took a guess, based upon the configure.ac generated by the original
"gnulib-tool" invocation.

Thanks - Bruce