automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Extend tests on AC_LIBOBJ and friends.


From: Ralf Wildenhues
Subject: Re: [PATCH] Extend tests on AC_LIBOBJ and friends.
Date: Mon, 13 Dec 2010 19:57:46 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

Hello Stefano,

* Stefano Lattarini wrote on Thu, Dec 09, 2010 at 09:41:46PM CET:
> From 88c5437de865d8d5574d12c1ba6256743987efc0 Mon Sep 17 00:00:00 2001
> From: Stefano Lattarini <address@hidden>
> Date: Tue, 31 Aug 2010 15:14:29 +0200
> Subject: [PATCH] Extend tests on AC_LIBOBJ and friends.
> 
> * tests/aclibobj.test: Removed, superseded by ...
> * tests/libobj1.test: ... this new test, which runs autoconf,

Can we agree on refraining testsuite removals to the absolute bare
minimum necessary, please?  I've mentioned before why they are harmful:
comparing old and new testsuite results is much more painful with them.
Also, one always risks lowering testsuite exposure.  So removals should
be limited to tests that are harmful in themselves only.  Renames have
some of the same problems.

> --- a/tests/aclibobj.test
> +++ b/tests/libobj15b.test

> @@ -14,36 +14,30 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>  
> -# Make sure AC_LIBOBJ and friends work.
> +# Nonexistent source for AC_LIBSOURCE should cause Automake to fail.
>  
>  . ./defs || Exit 1
>  
> +set -e
> +
>  cat >> configure.in << 'END'
>  AC_PROG_CC
>  AC_PROG_RANLIB
> +AC_LIBSOURCE([foobar.c])
> +# FIXME: without a call to AC_OUTPUT, Automake does not fail when file(s)
> +#        specified in AC_LIBSOURCE call(s) do not exist.  Should we fix
> +#        this limitation?  Or is the current behaviour good enough?

Instead of adding FIXMEs to the tests, please prefer to ask the question
on the list.  I know I could've just read the patch, but we've discussed
before (and I think agreed upon) that FIXMEs do not work, unless you
plan to fix it yourself soon afterwards.

With regard to this particular issue: users are supposed to call
AC_OUTPUT.  If they don't, tough luck for them.  Or vice versa: without
AC_OUTPUT, you don't need to assume correct semantics in the testsuite.

>  AC_OUTPUT
>  END

> --- a/tests/aclibobj.test
> +++ b/tests/libobj20c.test

> @@ -14,36 +14,40 @@
>  # You should have received a copy of the GNU General Public License
>  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
>  
> -# Make sure AC_LIBOBJ and friends work.
> +# Test error reporting for AC_CONFIG_LIBOBJ_DIR.
> +# See also sister tests `libobj20a.test' and `libobj20b.test' .
>  
>  . ./defs || Exit 1
>  
> +set -e
> +
>  cat >> configure.in << 'END'
> +AC_CONFIG_LIBOBJ_DIR([libobj-dir])
>  AC_PROG_CC
>  AC_PROG_RANLIB
> -AC_OUTPUT
> +AC_LIBOBJ([foobar])
>  END
>  
>  cat > Makefile.am << 'END'
> +AUTOMAKE_OPTIONS = subdir-objects ## required for our setup to work

Bug: ## comment preceded by something other than whitespace
(more than one instance of this).

>  noinst_LIBRARIES = libtu.a
>  libtu_a_SOURCES =
> -libtu_a_LIBADD = @LIBOBJS@
> +libtu_a_LIBADD = $(LIBOBJS)
>  END
>  
> -: > maude.c
> -: > liver.c
> -
>  $ACLOCAL
>  
> -set -e
> +AUTOMAKE_fails
> +grep 'configure\.in:.*required directory.*\./libobj-dir' stderr
> +
> +mkdir libobj-dir
> +: > foobar.c # oops, it should be in libobj-dir!
> +AUTOMAKE_fails
> +grep 'configure\.in:.*required file.*libobj-dir/foobar.c.*' stderr
>  
> -cp configure.in X
> -echo 'AC_LIBSOURCE(maude.c)' >> configure.in
> -$AUTOMAKE
> +rm -f foobar.c
>  
> -# Avoid timestamp-related differences.
> -rm -rf autom4te.cache
> +: > libobj-dir/foobar.c
> +$AUTOMAKE # now we should succeed
>  
> -cp X configure.in
> -echo 'AC_LIBSOURCES([maude.c, liver.c])' >> configure.in
> -$AUTOMAKE
> +:

Cheers,
Ralf



reply via email to

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