[adding bug-autoconf for AC_COMPILE_IFELSE comment] On 10 Oct 2010, at 21:35, Bruno Haible wrote: > Hi Gary,
Hallo Bruno, Thanks for the quick feedback. >> I think your script is *much* more complicated than it needs to be. Far >> easier to let the existing gnulib machinery populate an installable >> libposix project, surely? See below for my alternative two line script =)O| > > I agree that while a single-file bash script was a good way for Bruce to > communicate his progress with the rest of us, long-term it is better to do > that with a set of files in the git repository. > > Since creating a separate git repository is a lot of administrative work, > I would suggest that you (Bruce + Gary) create a subdirectory in gnulib, > called 'libposix', with files such as > configure.ac > Makefile.am > version.in.h > version.c > README > libposix.m4 > autogen.sh (or bootstrap if you prefer that) > and then use "gnulib-tool --import" instead of "gnulib-tool --create-testdir". Agreed. >> It occurs to me also, that when another gnulib using project (that relies on >> non-libposix modules) wants to minimise it's configury by requiring libposix, >> gnulib-tool will need an --avoid-posix option or similar so as not to end up >> pulling another copy of the posix modules and their dependencies into the >> new project. > > Hmm. That's a good point. But often the projects (especially coreutils) > need the newest stuff from gnulib, and a libposix.so that is 6 months old > will cover maybe 80% but not 100% of what coreutils wants. In that case, coreutils could drive impetus for a new release of libposix... an old libposix that is not good enough for coreutils is going to be deficient for other clients too. > But for other packages, which add libposix to their required dependencies, > such an option would be useful. Should I implement it? Other thoughts about > it? If you can add it easily, that would be great. I won't be able to make use of it until libposix is easily available though, so if it's anything other than trivial, it can wait until we've nailed down the libposix implementation. > What about the unit tests of gnulib modules, when a package is using an > installed > libposix? If the package specifies --with-test, only the tests for the non-libposix modules are needed... the build of libposix itself should have taken care of passing the posix module tests before it was installed (I'm seeing a failure there at the moment actually, but I'll post in a new thread). >> Also, while I understood why it was done at the time, the future of a >> comprehensive libposix looks bleak when fnmatch-posix, memset, strcspn and >> other arguably dangerous, but none-the-less posix specified api functions >> are marked as obsolete. I'd have a lot more confidence in a gnulib based >> libposix if those functions were marked instead as deprecated with a pointer >> to the better alternative. Obsolete suggests that support is going away. >> > > I think you are confusing the terms "deprecated" and "obsolete". In my > understanding, "deprecated" means "support is going away, please use the > suggested replacement". Whereas "obsolete" merely means "you don't need it". I understand them the other way around, yes. But, that's fine, as long as those libposix modules are not in imminent danger of removal from gnulib, I'm more than happy. >> ## Makefile.am: >> >> ACLOCAL_AMFLAGS = -I m4 >> SUBDIRS = libposix tests > > Ahem, there are two things missing here: > > - You want to install the library, which can be done by specifying to > gnulib-tool a module (via --local-dir) which contains > lib_LTLIBRARIES = libposix.la > When gnulib-tool sees this declaration in a module, it will not emit > noinst_LTLIBRARIES = libposix.la Okay, thanks. > - You want to install the header files, while transforming their > inclusion guard, for example, for stdlib.h: > s/_GL_STDLIB_H/_GLINST_STDLIB_H/ > Without it, strange things will happen when e.g. coreutils uses > stdlib.h from gnulib and its inclusion guard macro is the same as the > one of the installed stdlib.h. I hadn't gotten that far yet, but yes, agreed. >> 1. posix-modules vs strdup >> -------------------------- >> The posix-modules script outputs both 'strdup' and 'strdup-posix' causing >> a warning: 'This module is obsolete. But you may want to use the >> strdup-posix module.'. > > Is that a warning? I thought this was only a notice. > >> I had to filter the out put of posix-modules to use omit strdup to prevent >> that. > > You don't need to. Just ignore the notice. It would be nicer still to have the posix-modules script not emit 'strdup' though, no? >> 2. posix-modules vs alloca >> -------------------------- >> The modules specified by posix-modules require an LTALLOCA definition, >> per 'libposix/Makefile.am:35: @LTALLOCA@ used but `LTALLOCA' is undefined'. > > I think I fixed this last week. > > <http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=cdd4444161dffa8759a201d71801787b64db42dc> I think I may have caused that by also adding AC_FUNC_ALLOCA to configure.ac. I'll reraise the issue if it happens again. >> 3. missing AM_CONDITIONAL declarations >> -------------------------------------- >> I suppose the following definitions are supposed to have been added to >> gl_INIT >> somewhere, but `git grepping' around the gnulib sources didn't lead me to the >> culprit. >> >> libposix/Makefile.am:4192: LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR does not >> appear in AM_CONDITIONAL >> libposix/Makefile.am:4200: LIBUNISTRING_COMPILE_UNISTR_U8_UCTOMB does not >> appear in AM_CONDITIONAL >> libposix/Makefile.am:4240: LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH does not >> appear in AM_CONDITIONAL > > Strange, I haven't seen these. Can you prepare a real bug report (tarball with > commands to execute) which shows this? Definitely pilot error on my behalf. Please disregard this one. >> 4. pt_chown module >> ------------------ >> gnulib/modules/pt_chown hardcodes libgnu.a, so I had to edit the gnulib >> generated libposix/Makefile.am in libposix to refer to libposix.la instead. > > Yes, this seems unavoidable. I don't see how a program's LDADD could refer to > the library; what kind of syntax in the module description file would you > suggest for this? libgnu.a seems like a fine syntax already, and works well for --extract-xxx options too. I'd like to see gnulib-tool transform libgnu.a into whatever is appropriate according to --lib and --libtool/--no-libtool arguments without a manual post-gnulib-tool sed though. >> 5. AC_USE_SYSTEM_EXTENSIONS references >> -------------------------------------- >> This is just a warning, and doesn't prevent compilation so I didn't try to >> figure out exactly how to fix a series of these warnings: >> >> configure.ac:12: warning: AC_COMPILE_IFELSE was called before >> AC_USE_SYSTEM_EXTENSIONS >> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from... >> m4/gnulib-comp.m4:22: GL_EARLY is expanded from... >> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was >> called before AC_USE_SYSTEM_EXTENSIONS >> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from... >> m4/gnulib-comp.m4:22: GL_EARLY is expanded from... >> configure.ac:12: the top levelconfigure.ac:12: warning: AC_COMPILE_IFELSE >> was called before AC_USE_SYSTEM_EXTENSIONS >> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from... >> m4/gnulib-comp.m4:22: GL_EARLY is expanded from... >> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was >> called before AC_USE_SYSTEM_EXTENSIONS >> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from... >> m4/gnulib-comp.m4:22: GL_EARLY is expanded from... >> configure.ac:12: the top level > > The common way to get rid of these warnings is to insert an invocation of > gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac. Seems like a kludge to me. Either the AC_{RUN,COMPILE}_IFELSE using modules should AC_REQUIRE_ONCE([gl_USE_SYSTEM_EXTENSIONS]) themselves, or AC_{RUN, COMPILE}_IFELSE should invoke the require rather than the warning, no? And if that doesn't work, then AC_REQUIRE is not outputting macro expansions in the right order. What's the difference between AC_USE_SYSTEM_EXTENSIONS and gl_USE_SYSTEM_ EXTENSIONS? The warnings seem to indicate that adding AC_REQUIRE([AC_ USE_SYSTEM_EXTENSIONS]) to AC_{RUN,COMPILE}_IFELSE is the right solution. Cheers, -- Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part