Re: gnulib-tool feature request

[Sam Steingold]

On 3/2/10, Simon Josefsson <address@hidden> wrote:
>
>  > it would be not necessary if the --*-common arguments are introduced
>  > because then the macro prefix can be generated automatically.
>
>
> But I don't see how it would work because of module interdependency's.
>  I think there are two main cases:
>
>  1) There is only one configure.ac that runs both gnulib m4 scripts in
>    src/ and in the modules/foo/ directories.  (I'm using this model in
>    GNU Libidn, Shishi and GSS.)

this is not an option.
each module should be usable as is.
e.g., if you have clisp installed on your system, but, e.g., the
wildcard module is not supplied, you should be able to get the
wildcard module from the cvs (or tarball),
configure it, telling it which clisp installation to build against:
./configure --with-clisp=/usr/loca/bin/clisp
make && make install
and it is installed in your ~/.clisp/dynmod
and you can now use it like this:
$ clisp
> (require "wildcard")

Ergo: each module must have its own configure, which accepts --with-clisp
and uses build-aux &c based on that.

that's how it works now and that's how it should work in the future.

>  2) There are two configure.ac that has its own gnulib m4 scripts.  (I'm
>    using this model in GnuTLS and GNU SASL.)
>
>    You want the modules/foo/ directory to --avoid all modules from src/.
>
>    This will result in two config.h files and two _different_ system
>    replacement header files.  The system replacement header files will
>    provide conflicting definitions.  For example, if sys_socket.h is in
>    both src/ and modules/foo/ and modules/foo/ provides a declaration of
>    struct sockaddr_storage, the #include_next that points to the src/
>    copy also provides the same declaration, you'll get an error.

yes, alas, it appears that the headers would have to be duplicated.
however, the objects do not have to be.

>  > 2. I find this approach to be highly unaesthetic.
>  > One of the reasons we do FLOSS in our copious spare time is
>  > the desire to _reduce_ the ugliness - and when clisp has to be distributed
>  > with _several_ copies of most of gnu libc is ugly to the extreme.
>
> Sure.  I'm not sure how to resolve it though, without shipping the
>  _entire_ glibc code together with all packages and make sure that the
>  glibc replacement is built and used by all the remaining code that may
>  need different parts of the glibc code.

there is a more direct solution: make it illegal to use any OS other
than a recent linux.

-- 
Sam Steingold <http://sds.podval.org>