Hi Simon, > This causes vasnprintf.lo to be built, even though I don't need it! > > [EMAIL PROTECTED]:~/src/gnutls/lgl$ ls *.lo > asnprintf.lo gc-libgcrypt.lo md2.lo printf-parse.lo > vasnprintf.lo > dummy.lo gc-pbkdf2-sha1.lo printf-args.lo read-file.lo > [EMAIL PROTECTED]:~/src/gnutls/lgl$ > > Note that vasprintf.lo is not built. > > This situation seems sub-optimal.
We have lived with it so far; the only negative effect (other than a few milliseconds of build time) is that you get some dead code in the shared library. > Another solution would be for us to add a new statement in modules/* > files: 'Depends-on-optionally'. Then the vasprintf module could have > this patch: > > -Depends-on: > +Depends-on-optionally: > vasnprintf > + > +Depends-on: > stdio > > Gnulib-tool would do exactly the same as it does today for 'Depends-on', > that is pull in all the required modules and their dependencies > recursively, however, it would _not_ add the configure.ac statements > from the required modules into gnulib-comp.m4. You also need to specify somewhere under which conditions the dependency becomes real. In the static library case, it has been the linker who detects this automatically. Now, you need to specify it. Where and how should this be specified? > Still another alternative may be for the modules/vasnprintf file to > contain a more complex configure.ac statement, that wouldn't call the > vasnprintf M4 function all the time. However, it seems the generated > gnulib-comp.m4 is sorted alphanumerically rather than in > module-dependency order: > > gl_FUNC_VASNPRINTF > gl_FUNC_VASPRINTF This can be solved through some macrology. In general, sorting in alphabetic order guarantees reproducible results. There is no such thing as "module-dependency order" in general since there may be circular dependencies among modules. Bruno
