Re: gnulib-tool feature request

[Sam Steingold]

On 3/2/10, Simon Josefsson <address@hidden> wrote:
> Sam Steingold <address@hidden> writes:
>
> > On 3/1/10, Simon Josefsson <address@hidden> wrote:
>  >>
>  >> It would be nice it gnulib-tool could do it, but I have a hard time
>  >>  thinking how that would actually be implemented.  There are so many
>  >>  different ways you may want to organize your gnulib directories that
>  >>  having gnulib-tool support them all is probably going to overload the
>  >>  poor shell script.  Concrete ideas are always welcome, though...
>  >
>  > gnulib-tool accepts --source-base and --m4-base as destination for files.
>  > it should also accept --source-common and --m4-common which specify
>  > the location of modules which are in the "core" of the project, i.e., which
>  > can be assumed to be present.
>  > So I will write something like:
>  > gnulib-tool --source-base=src/gllib --m4-base=src/glm4 foo
>  > gnulib-tool --source-common=src/gllib --m4-common=src/glm4
>  >   --source-base=modules/syscalls/gllib --m4-base=modules/syscalls/glm4 bar
>  > and if bar depends on foo, then foo files will not be added to
>  > modules/syscalls/gllib
>  > and modules/syscalls/glm4, instead they will be found in src/gllib & 
> src/glm4
>  > by the second invocation of gnulib-tool.
>
>
> I don't think that approach works if modules/syscalls/ depends on a
>  gnulib module (e.g., chown or malloc) that needs to modify a system
>  header (i.e., unistd.h or stdlib.h) to work, and the system header is
>  already in src/.  Unfortunately, that is a quite common pattern in
>  gnulib.

this is precisely why I wrote that --macro-prefix patch!
it would be not necessary if the --*-common arguments are introduced
because then the macro prefix can be generated automatically.

>  Right now, I just let disk/CPU pay the price for this.
>  The runtime costs are quite small, if any, on any modern system.

1. how about embedded systems?

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.

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