bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnulib-tool --with-tests --test


From: Ralf Wildenhues
Subject: gnulib-tool --with-tests --test
Date: Thu, 9 Nov 2006 00:12:27 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

It would be nice if
  gnulib-tool --with-tests --test

succeeded out of the box, including actually running the tests.  IMHO
it would make a (one) good candidate for automatic testing.  Currently
it has (at least) the following issues:

- automake throws a warning about `po' not being mentioned in `SUBDIRS'.

- gltests/ is not autoreconf'ed, thus not configured and built either.
  If I manually run
    autoreconf -vi
  in there, autopoint does not like the fact that its installed files
  have been modified (by the bootstrap of the top directory).  It seems
    AUTOPOINT=true autoreconf -vi
  works, except for:

- gltests/configure.ac contains lines of the form
    AC_CONFIG_FILES([csharpcomp.sh:build-aux/csharpcomp.sh.in])

  that should be
    AC_CONFIG_FILES([csharpcomp.sh:../build-aux/csharpcomp.sh.in])

  and that lead to automake errors.

- The sub-configure in gltests fails because it looks for getloadavg.c
   in the wrong directory:
| configure: error: ../../gltests/gltests/getloadavg.c is missing
| configure: error: ../../gltests/configure failed for gltests

  I'd say there is an AC_CONFIG_LIBOBJ_DIR missing, but now that gnulib
  does things differently, I don't know how to fix this.

- I would like an option for gnulib-tool so that it does not remove the
  resulting directories after the test, and one to omit the 'distclean'.
  Manually inspecting the source and build trees helps to uncover more
  bugs.  For example:

- I get this output from a ../configure -C (in an empty directory):
| checking for working acl_get_file... no
| (cached) checking whether program_invocation_name is declared... yes
| checking whether program_invocation_short_name is declared... yes
| checking whether program_invocation_name is defined... yes
| checking whether program_invocation_short_name is defined... yes
| checking for argz.h... yes

  Note the '(cached) ' at the beginning of the line.  Not done
  investigating yet, but it seems a weird macro invocation vs.
  macro AC_REQUIREment issue again...

  After things are cached, the output even looks like this:
| checking for working acl_get_file... (cached) no
| (cached) (cached) checking whether program_invocation_name is declared... 
(cached) yes
| checking whether program_invocation_short_name is declared... (cached) yes
| checking whether program_invocation_name is defined... yes
| checking whether program_invocation_short_name is defined... yes
[...]

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]