improved Automake test for file names with funny characters
Following up on a discussion in the Autoconf and Automake mailing
lists, here's a proposed patch to Automake to have it test better for
file names with funny characters. If you look for the
expected_build_failures and expected_install_failures variables,
you'll see the test cases that Automake/Autoconf/Make etc. cannot
handle now. For example, file names containing '$'. I suppose that
these lists should either be shortened, or documented, or both.
The worst case are two tests that cause infinite loops. Ouch! The
script doesn't attempt to run those two tests. Look for 'infinite
loop' in the patch below.
Watch out: there are unusual control characters in this patch. I'll
attach a copy of the patched file too, just in case.
2005-07-01 Paul Eggert [EMAIL PROTECTED]
* tests/instspc.test: Major rewrite to test for many other
problematic file names, e.g., '$', '', '('. Automake and
Autoconf can't handle many of them, so report an expected
failure if the usual candidates show up.
Index: tests/instspc.test
===
RCS file: /cvs/automake/automake/tests/instspc.test,v
retrieving revision 1.3
diff -p -u -r1.3 instspc.test
--- tests/instspc.test 14 May 2005 20:28:55 - 1.3
+++ tests/instspc.test 1 Jul 2005 21:49:37 -
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2004 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -18,8 +18,9 @@
# the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
-# Check that installation to directory with spaces succeed.
-# Report from James Amundson.
+# Check that installation to directory with shell metacharacters succeed.
+# Original report from James Amundson about file names with spaces.
+# Other characters added by Paul Eggert.
# This is mostly the same input as nobase.test, but we do not use
# libtool libraries, because Libtool does not preserve space in
@@ -32,8 +33,7 @@ required='gcc'
set -e
-# Make sure this system supports spaces in filenames.
-mkdir 'a b' || exit 77
+# Set up files that won't change each time through the loop.
cat configure.in 'EOF'
AC_PROG_CC
@@ -41,6 +41,24 @@ AC_PROG_RANLIB
AC_OUTPUT
EOF
+mkdir sub
+
+: sub/base.h
+: sub/nobase.h
+: sub/base.dat
+: sub/nobase.dat
+: sub/base.sh
+: sub/nobase.sh
+
+cat source.c 'EOF'
+int
+main (int argc, char **argv)
+{
+ return 0;
+}
+EOF
+cp source.c source2.c
+
cat Makefile.am 'EOF'
foodir = $(prefix)/foo
fooexecdir = $(prefix)/foo
@@ -64,50 +82,135 @@ nobase_fooexec_LIBRARIES = sub/libnobase
sub_libbase_a_SOURCES = source.c
sub_libnobase_a_SOURCES = source.c
-test-install-space: install
- test -f $(DESTDIR)/more space/foo/sub/nobase.h
- test ! -f $(DESTDIR)/more space/foo/nobase.h
- test -f $(DESTDIR)/more space/foo/base.h
- test -f $(DESTDIR)/more space/foo/sub/nobase.dat
- test ! -f $(DESTDIR)/more space/foo/nobase.dat
- test -f $(DESTDIR)/more space/foo/base.dat
- test -f $(DESTDIR)/more space/foo/sub/nobase.sh
- test ! -f $(DESTDIR)/more space/foo/nobase.sh
- test -f $(DESTDIR)/more space/foo/base.sh
- test -f $(DESTDIR)/more space/foo/sub/nobase$(EXEEXT)
- test ! -f $(DESTDIR)/more space/foo/nobase$(EXEEXT)
- test -f $(DESTDIR)/more space/foo/base$(EXEEXT)
- test -f $(DESTDIR)/more space/foo/sub/libnobase.a
- test ! -f $(DESTDIR)/more space/foo/libnobase.a
- test -f $(DESTDIR)/more space/foo/libbase.a
+test-install-sep: install
+ test -f '$(DESTDIR)/$(file)-prefix/foo/sub/nobase.h'
+ test ! -f '$(DESTDIR)/$(file)-prefix/foo/nobase.h'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/base.h'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/sub/nobase.dat'
+ test ! -f '$(DESTDIR)/$(file)-prefix/foo/nobase.dat'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/base.dat'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/sub/nobase.sh'
+ test ! -f '$(DESTDIR)/$(file)-prefix/foo/nobase.sh'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/base.sh'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/sub/nobase$(EXEEXT)'
+ test ! -f '$(DESTDIR)/$(file)-prefix/foo/nobase$(EXEEXT)'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/base$(EXEEXT)'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/sub/libnobase.a'
+ test ! -f '$(DESTDIR)/$(file)-prefix/foo/libnobase.a'
+ test -f '$(DESTDIR)/$(file)-prefix/foo/libbase.a'
EOF
-mkdir sub
-
-: sub/base.h
-: sub/nobase.h
-: sub/base.dat
-: sub/nobase.dat
-: sub/base.sh
-: sub/nobase.sh
-
-cat source.c 'EOF'
-int
-main (int argc, char *argv[])
-{
- return 0;
-}
-EOF
-cp source.c source2.c
-
$ACLOCAL
$AUTOCONF
$AUTOMAKE -a
-mkdir build
-cd build
+# Some control characters that are white space:
+# back space, carriage return,
Re: aclocal performance
Hello, thanks for your interesting contribution. On Sat, Jun 11, 2005 at 12:36:17AM +1000, John Vandenberg wrote: I recently accidently ran into a ~10% performance improvement in aclocal. The attached patch requests autom4te only traces 'defun' macros that aclocal has noticed, rather than a static list of all the alternatives. If I understand correctly what your patch does, the speedup is lost as soon as you drop to /usr/share/aclocal a macro file which contains AC_DEFUN_ONCE and AU_DEFUN. I think that such kind of speedup is questionable. But what's more important, it can happen that an AC_DEFUN_ONCE is traced even though it wasn't directly visible when aclocal scanned the file. Yes, such a setup would be weird and dangerous, yet I think it's an argument that the current simple code should be preferred. I'm not sure whether there is a good reason why AU_ALIAS should not be traced; AU_ALIAS expands to AU_DEFUN. Tracing AU_ALIAS could slow things down. (So, with AU_ALIAS in a macro file, you code can actually get slower than the original.) Have a nice summer, Stepan Kasal
AC_PROG_CC_C_O
Hi, a bug report pointed me to AC_PROG_CC_C_O. The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O ad 1) Special needs of a project should be solved in that project. ad 2) The comments in automake/m4/minuso.m4 explain why Automake is not happy with the interface. And I think AM_PROG_CC_C_O should rather check only $CC, and not cc. So: No one is happy with the current macro. I think it should be deprecated. (The same with AC_PROG_FC_C_O and AC_PROG_F77_C_O which are not used at all.) AM_PROG_CC_C_O needs to test whether $CC -c -o works, but the interface should change. And does Automake have any plans for testing Fortran's -c -o? If yes, shouldn't we introduce a generalized macro, for example AC_LANG_COMPILER_C_O([IF-WORKS], [IF-DOESNT]) which would test the compiler of the current language? Looking forward for any feedback, Stepan
Re: AC_PROG_CC_C_O
Hi Stepan, * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. If yes, shouldn't we introduce a generalized macro, for example AC_LANG_COMPILER_C_O([IF-WORKS], [IF-DOESNT]) which would test the compiler of the current language? It would be great if, whatever solution turns out to be good for Autoconf and Automake, could also be aligned with Libtool in a sane way. Libtool currently has its own half-working macro for this. Combining is not as simple as it looks like: - if Automake and AM_PROG_CC_C_O are used, Libtool should be able to rely on $CC (which might be `compile ...') to work fine. Not using `compile' in this case would be an optimization (one shell script less to execute), though, albeit one where I don't know how to achieve it without Automake help. - otherwise, Libtool generally may need to do locking itself. The corresponding test should be aligned to Autoconf's, I guess, at least in the long run. Thus, it would be good if Autoconf/Automake provided a macro to test this, without also imposing `compile' in the failure case. One thing I can't remember (and have not searched in the archives yet) is whether some Intel compiler version does not understand `-c -o sub/out.o' (as opposed to `-c -o out.o') but exits with zero nonetheless, only issuing a warning. I do believe some compilers fail on subdir output only, though, gathering from the Libtool macro. Might be FUD, I really don't remember. I know all of this is little help for your task. ;) Regards, Ralf
Re: AC_PROG_CC_C_O
On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote: Hi Stepan, * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. All packages using subdir-objects (Flat Makefiles in deep source trees support) currently are using it. Ralf
Re: AC_PROG_CC_C_O
* Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST: On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote: * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. All packages using subdir-objects (Flat Makefiles in deep source trees support) currently are using it. Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses AM_PROG_CC_C_O, right? Regards, Ralf
Re: AC_PROG_CC_C_O
On Fri, 2005-07-01 at 15:23 +0200, Ralf Wildenhues wrote: * Ralf Corsepius wrote on Fri, Jul 01, 2005 at 03:20:22PM CEST: On Fri, 2005-07-01 at 14:33 +0200, Ralf Wildenhues wrote: * Stepan Kasal wrote on Fri, Jul 01, 2005 at 01:13:09PM CEST: The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. All packages using subdir-objects (Flat Makefiles in deep source trees support) currently are using it. Erm, Stepan talks about AC_PROG_CC_C_O, subdir-objects however uses AM_PROG_CC_C_O, right? Yep, I am referring to AM_PROG_CC_C_O, which according to the comment above internally uses AC_PROG_CC_C_O. Ralf
Re: AC_PROG_CC_C_O
Hello, On Fri, Jul 01, 2005 at 02:33:57PM +0200, Ralf Wildenhues wrote: The macro has two uses: 1) in GNU make's configure.in 2) in Automake's AM_PROG_CC_C_O How do you know nobody else uses it? It's published. Of course I don't know. But it's so poorly designed, that I think it's good to deprecate it. AC_LANG_COMPILER_C_O([IF-WORKS], [IF-DOESNT]) ... It would be great if, whatever solution turns out to be good for Autoconf and Automake, could also be aligned with Libtool in a sane way. I think that a cleanly designed test on Autoconf side is a good start for both Automake and Libtool. - if Automake and AM_PROG_CC_C_O are used, Libtool should be able to rely on $CC (which might be `compile ...') to work fine. Please note that automake/m4/minuso.m4 mentions plans to introduce something like AC_SUBST([am__CC], ['$(top_srcdir)/compile $(CC)']) Things might get interesting in future versions. - otherwise, Libtool generally may need to do locking itself. The corresponding test should be aligned to Autoconf's, I guess, at least in the long run. Again, the questionis whether AC_LANG_COMPILER_C_O would fit for this purpose. One thing I can't remember (and have not searched in the archives yet) is whether some Intel compiler version does not understand `-c -o sub/out.o' (as opposed to `-c -o out.o') but exits with zero nonetheless, only issuing a warning. I do believe some compilers fail on subdir output only, though, gathering from the Libtool macro. Might be FUD, I really don't remember. Let's fix it when it strikes. Stepan
Re: AC_PROG_CC_C_O
Hi, On Fri, Jul 01, 2005 at 04:08:50PM +0200, Ralf Corsepius wrote: All packages using subdir-objects (Flat Makefiles in deep source trees support) currently are using it. ... Yep, I am referring to AM_PROG_CC_C_O, which according to the comment above internally uses AC_PROG_CC_C_O. Of course, AM_PROG_CC_C_O may not be broken. Stepan
Re: I: adjust test suite for upcoming GNU Make 3.83
Hi all; I got no real response to this. This release of GNU make (3.81) is coming up (one hopes!) and this seems like a real problem that we need to come up with a solution for. If we don't it seems like automake and GNU make 3.81 and Java simply will not be usable together. Anyone have any thoughts or opinions on this? Reminding you; from the NEWS file for 3.81beta3: ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.bz2 * WARNING: Backward-incompatibility! GNU make now implements a generic second expansion feature on the prerequisites of both explicit and implicit (pattern) targets. After the rule has been parsed, the prerequisites are expanded a second time, this time with all the automatic variables in scope. This means that in addition to using standard SysV $$@ in prerequisites lists, you can also use complex functions such as $$(notdir $$@) etc. This behavior applies to implicit rules, as well, where the second expansion occurs after the rule is matched. However, this means that you need to double-quote any $ in your filenames; instead of foo: boo$$bar you must write foo: foobar. Since we last spoke, however, there has been a new feature added which may help somewhat: * New special variables available in this release: - .FEATURES: Contains a list of special features available in this version of GNU make. One of the words in the .FEATURES list will be second-expansion if this feature is present. However, I see no way to take advantage of this that is compatible with non-GNU versions of make. I don't know whether automake currently works correctly for Java with any other version of make, but this would definitely cause that not to be the case going forward. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: Include paths: no -I. please
I figured out the problem: for some reason, I couldn't just specify the option in the top-level Makefile.am. I had to specify it in the src directory's Makefile.am. (How come?) Thus spake Ralf Wildenhues on 6/30/2005 6:29 PM: * overbored wrote on Fri, Jul 01, 2005 at 12:44:38AM CEST: Thus spake Ralf Wildenhues on 6/30/2005 7:23 AM: Quoting the manual: | `nostdinc' | This option can be used to disable the standard `-I' options which | are ordinarily automatically provided by Automake. It's not working, -I. is still getting passed in. I re-ran the entire chain: aclocal autoconf automake ./configure make But I still see the two -I. arguments getting passed in. I cannot reproduce this with a small example. Could you try to provide a small example package where this fails? Regards, Ralf
Re: I: adjust test suite for upcoming GNU Make 3.83
FYI, here's one way to handle it (obviously requires GNU make): ifeq (,$(filter second-expansion,$(.FEATURES))) # GNU make 3.81 PRE_D := $$ else # GNU make =3.81 PRE_D := endif # Now use PRE_D in prerequisites all: foo$(PRE_D)bar ; @echo '$@: $' foo$$bar: ; @echo 'building $@' -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist
Re: I: adjust test suite for upcoming GNU Make 3.83
pds == Paul D Smith [EMAIL PROTECTED] writes: pds Hi all; pds I got no real response to this. This release of GNU make (3.81) is pds coming up (one hopes!) and this seems like a real problem that we need pds to come up with a solution for. If we don't it seems like automake and pds GNU make 3.81 and Java simply will not be usable together. I Paul. Your mail came in right when I was browsing my TODO list for things to do before Automake 1.9.6. One entry is ping about dollar.test. My last mail about this is here: http://lists.gnu.org/archive/html/automake/2005-03/msg00067.html [...] pds One of the words in the .FEATURES list will be second-expansion if this pds feature is present. pds However, I see no way to take advantage of this that is compatible with pds non-GNU versions of make. I can't see any way either. Is there a way to disable this feature? That might be the simplest solution. pds I don't know whether automake currently works correctly pds for Java with any other version of make, but this would pds definitely cause that not to be the case going forward. I believe $-filenames works only with GNU make. -- Alexandre Duret-Lutz
Re: I: adjust test suite for upcoming GNU Make 3.83
pds == Paul D Smith [EMAIL PROTECTED] writes: pds FYI, here's one way to handle it (obviously requires GNU make): pds ifeq (,$(filter second-expansion,$(.FEATURES))) pds # GNU make 3.81 pds PRE_D := $$ pds else pds # GNU make =3.81 pds PRE_D := pds endif pds # Now use PRE_D in prerequisites pds all: foo$(PRE_D)bar ; @echo '$@: $' pds foo$$bar: ; @echo 'building $@' The user lists filenames in variables, and Automake uses these variables in both prerequisite lists or commands. For instance see $(dist_my_DATA) in the last excerpt of http://lists.gnu.org/archive/html/automake/2005-03/msg00067.html So any solution that require a syntax that is different in prerequisites than it is in the commands seems wrong to me. Besides such a variable might as well defined from configure via a substitution, so Automake cannot do any preprocessing on its contents. -- Alexandre Duret-Lutz
