Bruno Haible <[EMAIL PROTECTED]> writes: > Simon Josefsson wrote: >> Yay! I considered dropping use of gnulib in libgnutls yesterday, >> because I wanted the error module for the tools, but that module need >> a program_name variable. When the library didn't provide one, there >> were linker failures. I added a dummy 'char *program_name = "gnutls"' >> inside the library now, but it is not a clean solution. > > The solution that you can already apply today is to use two different > invocations of gnulib-tool in different subdirectories of your package > (so that they don't collide on the filesystem), with different > configure.ac-s. With --macro-prefix you can cover both by the same > configure.ac.
Yup, I'm using two configure.ac's in gsasl, but I don't want to change gnutls to use the same scheme for only this reason. And with your work, I don't have to. > The ChangeLogs can be disabled through --no-changelog. The backup files > cannot be disabled. But you can remove them on your own afterwards. Excellent! >> > 1) Changed command-line invocation conventions: >> > "gnulib-tool --import abc" >> > followed by >> > "gnulib-tool --import def" >> > is equivalent to >> > "gnulib-tool --import abc def". >> > I.e. gnulib-tool memoizes the last parameters and reuses them. >> > "gnulib-tool --import" performs an update without changing the >> > parameters. >> >> Idea: an "--import --disable abc" or something to remove a module? > > Then we would need also > --import --remove-lgpl > --import --remove-libtool > --import --remove-avoid > These operations are not frequent. It's acceptable to tell the user to > modify the gnulib-cache.m4 file by hand and then run "gnulib-tool --import". Yes. I'm not sure I would use this interface myself, I probably edit gnulib-cache.m4 manually. For me, editing files is simpler than invoking commands. Remembering a command name is more difficult than locating an already existing file. >> > 2) An option --macro-prefix is introduced, so that the macros exported >> > by one gnulib.m4 may be called foo_EARLY, foo_INIT, and the ones in >> > another directory bar_EARLY, bar_INIT. >> > Also the parameters like module list, avoid list, etc. are stored >> > outside configure.ac. >> >> How about storing the parameters in the per-directory generated >> Makefile.am? > > An interesting idea: Indeed specifications usually go into .am files, not > .m4 files. But: > - The lib/Makefile.am contains stuff that will change by migrating to > new versions of gnulib, without changing the parameters. Therefore > lib/Makefile.am is a file that should be omitted from CVS. Whereas > the parameters belong into CVS. And it's not a good idea to merge > the two into a single file, as it would lead to frequent CVS conflicts. > - The m4/Makefile.am is considered obsolete since automake-1.9. > - Creating a new directory, whose purpose is only to hold a Makefile.am? > No. I don't know if it is a good idea, but maybe it would be possible to have a gnulib.mk that is included by the auto-generated Makefile.am. Then gnulib.mk could be stored in CVS, and hold the parameters. But this change sounds like work for no apparent gain, if the M4 approach work. >> Does this mean LTLIBOBJS will be foo_LTLIBOBJS instead? That would >> indeed be good news, I dislike the global nature of AC_REPLACE_FUNCS. > > I dislike that too. Currently I have to hack around AC_LIBSOURCES > and AC_LIBOBJ in order to avoid errors from automake. I'm sure Jim's and > Paul's change to use AC_LIBSOURCES in *.m4 files will cause problems here > again. Yes, if I used any non-gnulib AC_REPLACE_FUNCS in my configure.ac, I would have a problem with that change. But I think the real problem is AC_REPLACE_FUNC/LIBOBJ's rather than this change in gnulib. Thanks, Simon _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
