Re: installable gnulib library

[Bruno Haible]

Hi Gary,

> I think your script is *much* more complicated than it needs to be. Far
> easier to let the existing gnulib machinery populate an installable
> libposix project, surely? See below for my alternative two line script =)O|

I agree that while a single-file bash script was a good way for Bruce to
communicate his progress with the rest of us, long-term it is better to do
that with a set of files in the git repository.

Since creating a separate git repository is a lot of administrative work,
I would suggest that you (Bruce + Gary) create a subdirectory in gnulib,
called 'libposix', with files such as
  configure.ac
  Makefile.am
  version.in.h
  version.c
  README
  libposix.m4
  autogen.sh (or bootstrap if you prefer that)
and then use "gnulib-tool --import" instead of "gnulib-tool --create-testdir".

> 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 so as not to end up
> pulling another copy of the posix modules and their dependencies into the
> new project.

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?

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

> Also, while I understood why it was done at the time, the future of a
> comprehensive libposix looks bleak when fnmatch-posix, memset, strcspn and
> other arguably dangerous, but none-the-less posix specified api functions
> are marked as obsolete.  I'd have a lot more confidence in a gnulib based
> libposix if those functions were marked instead as deprecated with a pointer
> to the better alternative.  Obsolete suggests that support is going away.     

I think you are confusing the terms "deprecated" and "obsolete". In my
understanding, "deprecated" means "support is going away, please use the
suggested replacement". Whereas "obsolete" merely means "you don't need it".

There is no problem with having obsolete modules in libposix; they will
generate no code.

> The following works for me, by placing the following files in their own
> directory and running bootstrap -- barring a handful of small bugs in gnulib 
> that we can fix: 
> 
> # bootstrap:
> 
> #!/bin/sh
> gnulib-tool --import --lib=libposix --source-base=libposix --libtool 
> --with-tests `posix-modules`

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

> ## Makefile.am:
> 
> ACLOCAL_AMFLAGS = -I m4
> SUBDIRS = libposix tests

Ahem, there are two things missing here:

  - You want to install the library, which can be done by specifying to
    gnulib-tool a module (via --local-dir) which contains
      lib_LTLIBRARIES = libposix.la
    When gnulib-tool sees this declaration in a module, it will not emit
      noinst_LTLIBRARIES = libposix.la

  - You want to install the header files, while transforming their
    inclusion guard, for example, for stdlib.h:
      s/_GL_STDLIB_H/_GLINST_STDLIB_H/
    Without it, strange things will happen when e.g. coreutils uses
    stdlib.h from gnulib and its inclusion guard macro is the same as the
    one of the installed stdlib.h.

> ## 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_EARLY
> AM_PROG_CC_C_O
> gl_INIT
> AC_OUTPUT

Yes, this is a good start.

> 1. posix-modules vs strdup
> --------------------------
> The posix-modules script outputs both 'strdup' and 'strdup-posix' causing
> a warning: 'This module is obsolete. But you may want to use the
> strdup-posix module.'.

Is that a warning? I thought this was only a notice.

> I had to filter the out put of posix-modules to use omit strdup to prevent 
> that.

You don't need to. Just ignore the notice.

> 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'.

I think I fixed this last week.
  
<http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=cdd4444161dffa8759a201d71801787b64db42dc>

> 3. missing AM_CONDITIONAL declarations
> --------------------------------------
> I suppose the following definitions are supposed to have been added to gl_INIT
> somewhere, but `git grepping' around the gnulib sources didn't lead me to the
> culprit.  
> 
> libposix/Makefile.am:4192: LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR does not 
> appear in AM_CONDITIONAL
> libposix/Makefile.am:4200: LIBUNISTRING_COMPILE_UNISTR_U8_UCTOMB does not 
> appear in AM_CONDITIONAL
> libposix/Makefile.am:4240: LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH does not 
> appear in AM_CONDITIONAL

Strange, I haven't seen these. Can you prepare a real bug report (tarball with
commands to execute) which shows this?

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

> 5. AC_USE_SYSTEM_EXTENSIONS references
> --------------------------------------
> This is just a warning, and doesn't prevent compilation so I didn't try to
> figure out exactly how to fix a series of these warnings: 
> 
> configure.ac:12: warning: AC_COMPILE_IFELSE was called before 
> AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
> called before AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
> configure.ac:12: the top levelconfigure.ac:12: warning: AC_COMPILE_IFELSE was 
> called before AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
> called before AC_USE_SYSTEM_EXTENSIONS
> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
> configure.ac:12: the top level

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.

Bruno