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. Generally, the approach only seems to work if the gnulib modules used in src/ are self-contained, i.e., enabling the module doesn't cause other gnulib modules to behave differently. Right now gnulib-tool doesn't know whether a module is "standalone" or not -- but it could be encoded in the modules/ file. So if you want to implement this approach, I think you need to add a new field in the modules/ files 'Standalone: yes/no', and make gnulib-tool only put modules with 'Standalone: yes' in the src/ directory. Any module that has 'Standalone: no', or any module with 'Standalone: yes' but depends on any module with 'Standalone: no', must go into modules/syscalls/ etc. (Maintaining this information will be a pain though.) However, I'm not sure this will work out well. I suspect the number of gnulib modules that can be put into src/ and still work will be very small. A gnulib module that appear to be standalone may use some system call that does not work well on some platform, and thus ends up depending on that. For example: malloc. Then the otherwise standalone module cannot be put in the core directory. More ideas still welcome, or clarification if I'm missing something. I am experiencing problems in my projects over this gnulib design too (in particular, slow ./configure.ac time because of duplciation, and code duplication because all dependencies needs to be available in several places) but haven't been able to come up with a solution that is implementable. Right now, I just let disk/CPU pay the price for this. The runtime costs are quite small, if any, on any modern system. /Simon