On 3/2/10, Simon Josefsson <si...@josefsson.org> wrote: > Sam Steingold <s...@gnu.org> writes: > > > On 3/1/10, Simon Josefsson <si...@josefsson.org> 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>
