Re: first draft of "relocatable" module

[Bruno Haible]

Hello Ben,

> I've finished my first stab at a "relocatable" module for gnulib.

Thanks a lot for getting this rolling after so many years of stagnation
on my side!

> What I've done is essentially to assemble the relocatable stuff
> into a gnulib module, and then test it a little bit.  The first
> patch below shows this work.  Its contents are:
> 
>         * config.libpath, reloc-ldflags straight from gettext.

OK.

>         * relocatable.texi is my interpretation of Bruno's
>           http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html.
>           I hope it is all correct.

In gnulib we have two kinds of documentation: 1. Doc for the end-user,
copied into the using package and therefore mentioned in the module
description, and 2. Doc for the programmer or maintainer.
So far you've got doc #2. There is also a couple of paragraphs for the
user (discussing --enable-relocatable, --prefix etc.) in
  http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html
that you could copy into doc #1.

>         * progreloc.c needed to be updated for the changed
>           xreadlink interface.

The xreadlink interface needs Jim's opinion. The <unistd.h> change is ok.

>         * relocatable.c is from gettext, but I was able to take
>           advantage of new gnulib modules to drop quite a bit of
>           boilerplate from the beginning.  Perhaps my use of the
>           c-ctype module will be rejected, but I hope that the
>           rest is not controversial.

However, relocatable.c is also used in libraries that are made
relocatable. This is more complicated than the case of relocatable programs,
but with some care I was able use the same code. In particular, libintl
uses this code, and it is thus copied into every package that uses
"gettextize --intl" (e.g. grep or binutils). Therefore here I find it good
to avoid dependencies to too many gnulib files. Especially dependencies to
GPLed modules, since relocatable.c must be LGPL for libintl to include it.

Therefore here I'm against the use of <stdbool.h>, filename.h, and xalloc.h.
Also I didn't see where you moved the _GNU_SOURCE setting to.

>           relocwrapper.c is similar, with fewer changes.

These changes are OK, assuming the change to install-reloc that you did.

>           Ditto for relocatable.m4.

Where did the AC_EXEEXT invocation go?

>         * relocatable.h is from gettext, without change.

OK.

>         * relocatable.sh.in is an extract from gettext's
>           gettextize.sh.in explained in relocatable.texi.

OK. But the largest part of this shell script code is not to be modified
by the maintainer. Can you make this code available through a single
autoconf variable (assuming autoconf-2.61) or through some Makefile.am
rule? For the part which contains the variables needed by the script,
this is obviously not fully automatable on the gnulib side; documenting
the customization/adaptation steps, like you did, is fine.

>         * I wrote modules/relocatable myself.

This is GPL, but libraries need part of it under LGPL, namely: relocatable.h,
relocatable.c, and the macros AC_RELOCATABLE_LIBRARY and AC_RELOCATABLE_NOP
from relocatable.m4? Can you group them into a module 'relocatable-lib'
that 'relocatable' depends upon?

I'm not sure whether then it's also worth making a separate
'relocatable-script' module that takes care of the mechanics for the
relocatable shell scripts?

> Now, my questions, which I hope do not sound too stupid:
> 
>         * First, the Automake variables required for
>           relocatability.  It seems like three of these
>           (RELOCATABLE_SRC_DIR, RELOCATABLE_BUILD_DIR,
>           RELOCATABLE_CONFIG_H_DIR) are completely mechanical and
>           that they could just be produced by AC_RELOCATABLE and
>           AC_SUBST'd.  Any reason not to do that?

Yes, good point. This is possible. You can refer to $(top_srcdir) and
$(top_builddir).

>         * It seems that $(libdir) is a reasonable default for
>           RELOCATABLE_LIBRARY_PATH.  Is it reasonable to make
>           this an optional argument to AC_RELOCATABLE and use
>           $(libdir) as the default?

The idea of having a default is good. What should the default be? In
simple cases, such as GNU hello, the package installs only programs, not
libraries. Therefore I think the default should be empty. (GNU gettext uses
$(libdir), because it's there that it installs libintl.so.)

There is this optimization in install-reloc:
  # If there are no library directories to add at runtime, we don't need a
  # wrapper.
  test -n "$libdirs" || exit 0

If you make $(libdir) the default, this optimization will be disabled for
the packages that rely on this default.

>         * @SET_RELOCATABLE@ just expands to a variable
>           definition.  Do we need this extra level of
>           indirection?

What could you simplify here? I don't see it.

>         * The suggested method of setting INSTALLDIR uses a
>           program-specific variable.  I think that this prevents
>           sharing object files between programs, increasing the
>           number of compilations necessary if programs share
>           source files.

Yes, I think so too.

>           If so, should we instead generate a .c
>           file that defines orig_installdir and
>           orig_installprefix?

An interesting idea. I would say yes if it doesn't increase the number of
variables to be declared manually in the Makefile.am. If it causes hassles
to the package maintainer, however, I'd say no - since we're talking only
about an optimization.

>         * Should I rename AC_RELOCATABLE to gl_RELOCATABLE?

Yes please. I'm no longer following the goal of pushing this into autoconf.
Therefore 'gl_' is the right prefix.

>         * It looks like Automake support is wanted for
>           automatically defining foo_CFLAGS and foo_LDFLAGS.  Any
>           suggestion about what mechanism should be used to
>           trigger this?  e.g. something in AUTOMAKE_OPTIONS, a
>           magic AM_CONDITIONAL directive, something else?  Being
>           no Automake guru I'm not sure what would be considered
>           in the "spirit of Automake" here.

Ralf?

Bruno