Re: [PATCH] docs: more details about make VPATH rewriting woes
* Stefano Lattarini wrote on Thu, Sep 15, 2011 at 11:21:16AM CEST: On Thursday 15 September 2011, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Wed, Sep 14, 2011 at 11:35:37AM CEST: On Wednesday 14 September 2011, Ralf Wildenhues wrote: It applies to any word that is surrounded by whitespace (or beginning or end of command line), regardless of shell syntax. Please don't formulate it like Solaris make would understand shell syntax when rewriting rules, IMHO that's confusing and makes it harder to understand the issue. You're right, my previous formulation was somewhat confusing in this regard. What about the squash-in below? Fine with me, thanks. Should I take this as an ACK to push? On my side, sure. I think Eric would have complained if he wanted to. :-) also, for American English type setting, you'd write an emdash as three hyphens and no space right before and afterwards, That is just horribly ugly IMHO, almost as bad as a final dot inside double quotes. I refuse to voluntarily use those formatting in the text I write :-) I went for the comma instead. You dislike the final dot inside double quotes? But in typeset text, the spacing can be really ugly when it's outside. But I digress ... Cheers, Ralf
Re: [PATCH 2/2] New macro AC_FC_MODULE_FLAG: Fortran 90 module include path.
* Ralf Wildenhues wrote on Sun, Mar 06, 2011 at 01:54:07PM CET:
* lib/autoconf/fortran.m4 (AC_FC_MODULE_FLAG): New macro,
adjusted and rewritten from the AX_F90_MODULE_FLAG macro from
the Autoconf Macro Archive by Luc Maisonobe, Julian C. Cummings,
and Alexander Pletzer.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/fortran.at (AC_FC_MODULE_FLAG): New test.
* tests/local.at (AT_CHECK_ENV): Do not complain about FC_MODINC
setting.
* THANKS: Update.
This patch needed a fixup for gfortran 4.4 so it wouldn't choose -M
as include flag, as below. (I would like Sun f95 to prefer -M over
-I for module inclusion, as the latter also governs header inclusion.)
Cheers,
Ralf
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index b03af38..25b0540 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1570,12 +1570,13 @@ AC_SUBST([FC_MODEXT])dnl
# It may contain significant trailing whitespace.
#
# Known flags:
-# gfortran: -Idir, -I dir (-M dir (deprecated), -Jdir for writing)
+# gfortran: -Idir, -I dir (-M dir, -Mdir (deprecated), -Jdir for writing)
# g95: -I dir (-fmod=dir for writing)
# SUN: -Mdir, -M dir (-moddir=dir for writing;
# -Idir for includes is also searched)
# HP: -Idir, -I dir (+moddir=dir for writing)
# IBM: -Idir (-qmoddir=dir for writing)
+# Intel: -Idir -I dir (-mod dir for writing)
# Absoft: -pdir
# Lahey: -mod dir
# Cray: -module dir, -p dir (-J dir for writing)
@@ -1588,7 +1589,8 @@ AC_SUBST([FC_MODEXT])dnl
#(-Am indicates how module information is saved)
AC_DEFUN([AC_FC_MODULE_FLAG],[
AC_CACHE_CHECK([Fortran 90 module inclusion flag], [ac_cv_fc_module_flag],
-[AC_LANG_PUSH(Fortran)
+[AC_LANG_PUSH([Fortran])
+ac_cv_fc_module_flag=unknown
mkdir conftest.dir
cd conftest.dir
AC_COMPILE_IFELSE([[
@@ -1599,11 +1601,11 @@ AC_COMPILE_IFELSE([[
end subroutine
end module]],
[cd ..
- ac_cv_fc_module_flag=unknown
ac_fc_module_flag_FCFLAGS_save=$FCFLAGS
# Flag ordering is significant for gfortran and Sun.
for ac_flag in -M -I '-I ' '-M ' -p '-mod ' '-module ' '-Am -I'; do
- FCFLAGS=$ac_fc_module_flag_FCFLAGS_save ${ac_flag}conftest.dir
+ # Add the flag twice to prevent matching an output flag.
+ FCFLAGS=$ac_fc_module_flag_FCFLAGS_save ${ac_flag}conftest.dir
${ac_flag}conftest.dir
AC_COMPILE_IFELSE([[
program main
use conftest_module
@@ -1617,7 +1619,7 @@ AC_COMPILE_IFELSE([[
FCFLAGS=$ac_fc_module_flag_FCFLAGS_save
])
rm -rf conftest.dir
-AC_LANG_POP(Fortran)
+AC_LANG_POP([Fortran])
])
if test $ac_cv_fc_module_flag != unknown; then
FC_MODINC=$ac_cv_fc_module_flag
Re: [PATCH 0/2] Fortran 90 module file extension and include path
Hello, and sorry for the delay, * Julian Cummings wrote on Thu, Mar 10, 2011 at 02:01:41AM CET: My first question would be how to properly credit the original authors of these macros. Luc, Julian, Alexander, I'd be glad to list y'all as authors and add you to the Autoconf THANKS file if you don't mind. For git purposes, I'm not sure whether to list one of you as primary author and if yes who. My recollection is also that Luc was the original author, and others including myself added patches. OK. I've pushed the patches now in Luc's name, and added everyone to THANKS. Hope that's OK for everyone. Thanks. Last, but not least, patch feedback would be great, of course! I could probably test this out with several compilers that I have access to here. How do I access the patches? Have they been rolled into a recent autoconf tarball? Not yet. What you can do is try the git tree. For that, ensure you have a fairly recent Autoconf + Automake installed, then: git clone git://git.sv.gnu.org/autoconf.git cd autoconf autoreconf -vim make check TESTSUITEFLAGS='-v -d -k AC_F[7C].* -k fortran' and watch the output for any non-PASSing tests; even SKIPs can, but don't have to, hint towards issues. We have to be a bit conservative in the test suite to avoid feedback noise. In order to test specific compilers, pass values for CC=..., F77, FC in TESTSUITEFLAGS as well. Thank you, Ralf
Re: New macro AC_FC_PP_SRCEXT for preprocessed file extensions.
* Ralf Wildenhues wrote on Sat, Mar 05, 2011 at 07:59:27PM CET: I haven't pushed this patch yet; I'd really appreciate some comments. No comments, I've pushed this patch now, with minor testsuite fixes as below folded in. Thanks, Ralf New macro AC_FC_PP_SRCEXT for preprocessed file extensions. * lib/autoconf/fortran.m4 (AC_FC_PP_SRCEXT): New macro. * lib/autom4te.in (Automake-preselections): Preselect it. * doc/autoconf.texi (Fortran Compiler): Document it, rewriting the documentation for AC_FC_SRCEXT along the way. * tests/fortran.at (AC_FC_PP_SRCEXT usage): New test. * tests/mktests.sh: Exclude the macro from default testing. * NEWS: Update. diff --git a/tests/fortran.at b/tests/fortran.at index 346baa0..524a8c3 100644 --- a/tests/fortran.at +++ b/tests/fortran.at @@ -753,9 +753,9 @@ prog@EXEEXT@: foof.@OBJEXT@ @f77_object@ @f90_object@ \ .SUFFIXES: .f .f77 .f90 .f95 .f03 .f08 .F .F77 .F90 .F95 .F03 .F08 .@OBJEXT@ .f.@OBJEXT@: - @FC@ -c @FCFLAGS_f@ $ + @FC@ -c @FCFLAGS@ @FCFLAGS_f@ $ .f77.@OBJEXT@: - @FC@ -c @FCFLAGS_f77@ $ + @FC@ -c @FCFLAGS@ @FCFLAGS_f77@ $ .f90.@OBJEXT@: @FC@ -c @FCFLAGS@ @FCFLAGS_f90@ $ .f95.@OBJEXT@: @@ -765,9 +765,9 @@ prog@EXEEXT@: foof.@OBJEXT@ @f77_object@ @f90_object@ \ .f08.@OBJEXT@: @FC@ -c @FCFLAGS@ @FCFLAGS_f08@ $ .F.@OBJEXT@: - @FC@ -c @FCFLAGS_F@ $ + @FC@ -c @FCFLAGS@ @FCFLAGS_F@ $ .F77.@OBJEXT@: - @FC@ -c @FCFLAGS_F77@ $ + @FC@ -c @FCFLAGS@ @FCFLAGS_F77@ $ .F90.@OBJEXT@: @FC@ -c @FCFLAGS@ @FCFLAGS_F90@ $ .F95.@OBJEXT@:
New macro AC_FC_PP_DEFINE for the preprocessor define flag.
The infrastructure for handling preprocessed Fortran better is still
lacking quite a bit; e.g., it would be nice to generate lazily-updated
config headers with Fortran-style comments. For now, I use this as a
workaround in projects:
AC_CONFIG_HEADERS([config.h])
# Convert config.h into an fconfig.h suitable for inclusion into Fortran.
# The sed script transforms C style /* comments */ into Fortran style.
AC_CONFIG_HEADERS([fconfig.h],
[[sed '
/\/\*\(.*\)\*\//{
s,,!\1,p
d
}
/\/\*/,/\*\//{
s,/\*,,
s,\*/,,
s,^,!,p
d
}' fconfig.h fconfig.ht
mv -f fconfig.ht fconfig.h
]])
One thing that is still needed for basic support is a macro for the
define flag; thanks to IBM xlf, -D does not work universally. (I've
gathered the other spellings by looking at manuals only, no testing.)
For example, we can use this macro with above snippet as
FCFLAGS=$FCFLAGS ${FC_DEFINE}HAVE_FCONFIG_H
(and later on, we want to have a FCDEFS variable and automake rules to
pick up this junk all by itself ...)
Pushed to master.
Cheers,
Ralf
New macro AC_FC_PP_DEFINE for the preprocessor define flag.
* lib/autoconf/fortran.m4 (AC_FC_PP_DEFINE): New macro.
* lib/autom4te.in (Automake-preselections): Preselect it.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/local.at (_AT_CHECK_ENV): Do not complain about
FCFLAGS_F nor FC_DEFINE.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index d09e0f4..c44678d 100644
--- a/NEWS
+++ b/NEWS
@@ -20,6 +20,7 @@ GNU Autoconf NEWS - User visible changes.
AC_FC_MODULE_FLAG for the Fortran 90 module search path flag
AC_FC_MODULE_OUTPUT_FLAG for the Fortran 90 module output directory flag
AC_FC_PP_SRCEXT for preprocessed Fortran source files extensions
+AC_FC_PP_DEFINE for the Fortran preprocessor define flag
* Noteworthy changes in release 2.68 (2010-09-22) [stable]
Released by Eric Blake, based on git versions 2.67.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 730b590..d553f4a 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8262,6 +8262,25 @@ Fortran Compiler
@code{ac_cv_fc_pp_srcext_@var{ext}} variables, respectively.
@end defmac
+@defmac AC_FC_PP_DEFINE (@ovar{action-if-success}, @dvar{action-if-failure, @
+ AC_MSG_FAILURE})
+@acindex{FC_PP_DEFINE}
+@caindex fc_pp_define
+
+Find a flag to specify defines for preprocessed Fortran. Not all
+Fortran compilers use @option{-D}. Substitute @code{FC_DEFINE} with
+the result and call @var{action-if-success} (defaults to nothing) if
+successful, and @var{action-if-failure} (defaults to failing with an
+error message) if not.
+
+This macro calls @code{AC_FC_PP_SRCEXT([F])} in order to learn how to
+to preprocess a @file{conftest.F} file, but restores a previously used
+Fortran source file extension afterwards again.
+
+The result of this test is cached in the @code{ac_cv_fc_pp_define}
+variable.
+@end defmac
+
@defmac AC_FC_FREEFORM (@ovar{action-if-success}, @dvar{action-if-failure, @
AC_MSG_FAILURE})
@acindex{FC_FREEFORM}
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 1c31392..56488a9 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1275,6 +1275,56 @@ AC_LANG_POP(Fortran)dnl
])# AC_FC_PP_SRCEXT
+# AC_FC_PP_DEFINE([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+# ---
+# Find a flag to specify defines for preprocessed Fortran. Not all
+# Fortran compilers use -D. Substitute FC_DEFINE with the result and
+# call ACTION-IF-SUCCESS (defaults to nothing) if successful, and
+# ACTION-IF-FAILURE (defaults to failing with an error message) if not.
+#
+# Known flags:
+# IBM: -WF,-D
+# Lahey/Fujitsu: -Wp,-D older versions???
+# f2c: -D or -Wc,-D
+# others: -D
+AC_DEFUN([AC_FC_PP_DEFINE],
+[AC_LANG_PUSH([Fortran])dnl
+ac_fc_pp_define_srcext_save=$ac_fc_srcext
+AC_FC_PP_SRCEXT([F])
+AC_CACHE_CHECK([how to define symbols for preprocessed Fortran],
+ [ac_cv_fc_pp_define],
+[ac_fc_pp_define_srcext_save=$ac_fc_srcext
+ac_cv_fc_pp_define=unknown
+ac_fc_pp_define_FCFLAGS_save=$FCFLAGS
+for ac_flag in -D -WF,-D -Wp,-D -Wc,-D
+do
+ FCFLAGS=$ac_fc_pp_define_FCFLAGS_save ${ac_flag}FOOBAR ${ac_flag}ZORK=42
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [[
+#ifndef FOOBAR
+ choke me
+#endif
+#if ZORK != 42
+ choke me
+#endif]])],
+[ac_cv_fc_pp_define=$ac_flag])
+ test x$ac_cv_fc_pp_define != xunknown break
+done
+FCFLAGS=$ac_fc_pp_define_FCFLAGS_save
+])
+ac_fc_srcext=$ac_fc_pp_define_srcext_save
+if test x$ac_cv_fc_pp_define = xunknown; then
+ FC_DEFINE=
+ m4_default([$2],
+[AC_MSG_ERROR([Fortran does not allow to define preprocessor
symbols], 77)])
+else
+ FC_DEFINE=$ac_cv_fc_pp_define
+ $1
+fi
+AC_SUBST([FC_DEFINE])dnl
+AC_LANG_POP([Fortran])dnl
+])
+
+
# AC_FC_FREEFORM([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
#
Re: [PATCH] README-hacking: fix typo
Hi Jim, * Jim Meyering wrote on Sat, Mar 26, 2011 at 09:51:15PM CET: Here's a tiny fix: Subject: [PATCH] README-hacking: fix typo * README-hacking: s/just build/just built/. Pushed, thanks! Cheers, Ralf
Re: docs: BSD and Solaris make trailing space macro issue.
* Paul Eggert wrote on Sun, Mar 06, 2011 at 06:33:36PM CET: Instead of this: # The following line contains a trailing space. foo = bar I suggest this: foo = bar # Note the space after bar. Sounds good. Thanks! Ralf
docs: BSD and Solaris make trailing space macro issue.
OK to push?
This prepares the next couple of patches. Yes, it adds a trailing space
in the manual source. I'm not sure how useful that is, given that it
doesn't survive in the .info output. Suggestions welcome.
Thanks,
Ralf
docs: BSD and Solaris make trailing space macro issue.
* doc/autoconf.texi (Trailing whitespace in Make Macros):
Document issue with trailing whitespace in macro settings.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b552883..c537335 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19853,6 +19853,20 @@ Trailing whitespace in Make Macros
@noindent
prints @samp{bar.test .test}.
+BSD and Solaris @command{make} implementations do not honor trailing
+whitespace in macro definitions as Posix requires:
+
+@example
+# The following line contains a trailing space.
+foo = bar
+print: ; @@echo $(foo)t
+@end example
+
+@noindent
+prints @samp{bart} instead of @samp{bar t}. To work around this, you
+can use a helper macro as in the previous example.
+
+
@node Command-line Macros and whitespace
@section Command-line Macros and whitespace
@cindex whitespace in command-line macros
[PATCH 0/2] Fortran 90 module file extension and include path
Hello everyone, I would like to see improved Fortran support in Autotools, and for eventual dependency tracking in Automake (and other purposes) we need to know the name of module files and how to modify the include path. Now, the AX_F90_MODULE_EXTENSION and AX_F90_MODULE_FLAG macros from the Autoconf Macro Archive provide nice initial macros for this purpose. I'd like to integrate them in Autoconf proper, and to that end I've done some rewriting of them, changed semantics a bit, added a couple more flags I know of, and some documentation. My first question would be how to properly credit the original authors of these macros. Luc, Julian, Alexander, I'd be glad to list y'all as authors and add you to the Autoconf THANKS file if you don't mind. For git purposes, I'm not sure whether to list one of you as primary author and if yes who. Then, I've resorted to some hacking in order to preserve trailing whitespace in the FC_MODINC value in a Makefile, and also retain its usefulness in the configure script. Could also do without a helper var, as in something like case $FC_MODINC in *\ ) FC_MODINC=$FC_MODINC\'\' ;; esac if that is preferable. The testsuite addition in the second patch is probably too strict, but I'd prefer to hear about compilers that don't provide any flag. Last, but not least, patch feedback would be great, of course! Thanks, Ralf
[PATCH 1/2] New macro AC_FC_MODULE_EXTENSION: Fortran 90 module extension.
* lib/autoconf/fortran.m4 (AC_FC_MODULE_EXTENSION): New macro,
rewritten from the AX_F90_MODULE_EXTENSION macro from the
Autoconf Macro Archive by Luc Maisonobe and Alexander Pletzer.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/local.at (_AT_CHECK_ENV): Do not complain about
FC_MODEXT setting.
* THANKS: Update.
---
ChangeLog | 13 +
doc/autoconf.texi | 33 +
lib/autoconf/fortran.m4 | 35 +++
tests/local.at |3 ++-
4 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ed4c467..9570ce7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2011-03-06 Luc Maisonobe ...
+ Alexander Pletzer ...
+ Ralf Wildenhues ...
+
+ New macro AC_FC_MODULE_EXTENSION: Fortran 90 module extension.
+ * lib/autoconf/fortran.m4 (AC_FC_MODULE_EXTENSION): New macro,
+ rewritten from the AX_F90_MODULE_EXTENSION macro from the
+ Autoconf Macro Archive by Luc Maisonobe and Alexander Pletzer.
+ * doc/autoconf.texi (Fortran Compiler): Document it.
+ * tests/local.at (_AT_CHECK_ENV): Do not complain about
+ FC_MODEXT setting.
+ * THANKS: Update.
+
2011-03-05 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix Cray Fortran flag for AC_FC_IMPLICIT_NONE.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b552883..f3a87d1 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8345,6 +8345,39 @@ Fortran Compiler
variables, respectively.
@end defmac
+@defmac AC_FC_MODULE_EXTENSION
+@acindex{FC_MODULE_EXTENSION}
+@caindex fc_module_ext
+@ovindex FC_MODEXT
+
+Find the Fortran 90 module file name extension. Most Fortran 90
+compilers store module information in files separate from the object
+files. The module files are usually named after the name of the module
+rather than the source file name, with characters possibly turned to
+upper case, plus an extension, often @file{.mod}.
+
+Not all compilers use module files at all, or by default. The Cray
+Fortran compiler requires @option{-e m} in order to store and search
+module information in @file{.mod} files rather than in object files.
+Likewise, the Fujitsu Fortran compilers uses the @option{-Am} option to
+indicate how module information is stored.
+
+The @code{AC_FC_MODULE_EXTENSION} macro computes the module extension
+without the leading dot, and stores that in the @code{FC_MODEXT}
+variable. If the compiler does not produce module files, or the
+extension cannot be determined, @code{FC_MODEXT} is empty. Typically,
+the result of this macro may be used in cleanup @command{make} rules as
+follows:
+
+@example
+clean-modules:
+-test -z $(FC_MODEXT) || rm -f *.$(FC_MODEXT)
+@end example
+
+The extension, or @samp{unknown}, is cached in the
+@code{ac_cv_fc_module_ext} variable.
+@end defmac
+
@node Go Compiler
@subsection Go Compiler Characteristics
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 84f3162..864fcaa 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1524,3 +1524,38 @@ AC_DEFUN([AC_FC_IMPLICIT_NONE],
_AC_FC_IMPLICIT_NONE($@)
AC_LANG_POP([Fortran])dnl
])# AC_FC_IMPLICIT_NONE
+
+
+# AC_FC_MODULE_EXTENSION
+# --
+# Find the Fortran 90 module file extension. The module extension is stored
+# in the variable FC_MODEXT and empty if it cannot be determined. The result
+# or unknown is cached in the cache variable ac_cv_fc_module_ext.
+AC_DEFUN([AC_FC_MODULE_EXTENSION],
+[AC_CACHE_CHECK([Fortran 90 module extension], [ac_cv_fc_module_ext],
+[AC_LANG_PUSH(Fortran)
+mkdir conftest.dir
+cd conftest.dir
+ac_cv_fc_module_ext=unknown
+AC_COMPILE_IFELSE([[
+ module conftest_module
+ contains
+ subroutine conftest_routine
+ write(*,'(a)') 'gotcha!'
+ end subroutine
+ end module]],
+ [ac_cv_fc_module_ext=`ls | sed -n 's,conftest_module\.,,p'`
+ if test x$ac_cv_fc_module_ext = x; then
+dnl Some F90 compilers use upper case characters for the module file name.
+ ac_cv_fc_module_ext=`ls | sed -n 's,CONFTEST_MODULE\.,,p'`
+ fi])
+cd ..
+rm -rf conftest.dir
+AC_LANG_POP(Fortran)
+])
+FC_MODEXT=$ac_cv_fc_module_ext
+if test $FC_MODEXT = unknown; then
+ FC_MODEXT=
+fi
+AC_SUBST([FC_MODEXT])dnl
+])
diff --git a/tests/local.at b/tests/local.at
index bfd124f..e08d8b1 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -317,7 +317,7 @@ if test -f state-env.before test -f state-env.after; then
[cross_compiling|U],
[interpval|PATH_SEPARATOR],
[F77_DUMMY_MAIN|f77_(case|underscore)],
- [FC(_DUMMY_MAIN|FLAGS|LIBS|FLAGS_f)?],
+ [FC(_DUMMY_MAIN|FLAGS|LIBS|FLAGS_f|_MODEXT)?],
[ALLOCA|GETLOADAVG_LIBS|KMEM_GROUP|NEED_SETGID|POW_LIB],
[AWK|LEX|LEXLIB|LEX_OUTPUT_ROOT|LN_S|M4|MKDIR_P|RANLIB|SET_MAKE|YACC],
[GREP|[EF]GREP|SED],
@@ -368,6 +368,7 @@ do
/^m4_defn([m4_re_word])=./ !d
[PATCH 2/2] New macro AC_FC_MODULE_FLAG: Fortran 90 module include path.
* lib/autoconf/fortran.m4 (AC_FC_MODULE_FLAG): New macro,
adjusted and rewritten from the AX_F90_MODULE_FLAG macro from
the Autoconf Macro Archive by Luc Maisonobe, Julian C. Cummings,
and Alexander Pletzer.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/fortran.at (AC_FC_MODULE_FLAG): New test.
* tests/local.at (AT_CHECK_ENV): Do not complain about FC_MODINC
setting.
* THANKS: Update.
---
ChangeLog | 16 ++
doc/autoconf.texi | 45
lib/autoconf/fortran.m4 | 75 +++
tests/fortran.at| 71
tests/local.at |2 +-
5 files changed, 208 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 9570ce7..fabd8fb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,20 @@
2011-03-06 Luc Maisonobe ...
+ Julian C. Cummings ...
+ Alexander Pletzer ...
+ Ralf Wildenhues ...
+
+ New macro AC_FC_MODULE_FLAG: Fortran 90 module include path.
+ * lib/autoconf/fortran.m4 (AC_FC_MODULE_FLAG): New macro,
+ adjusted and rewritten from the AX_F90_MODULE_FLAG macro from
+ the Autoconf Macro Archive by Luc Maisonobe, Julian C. Cummings,
+ and Alexander Pletzer.
+ * doc/autoconf.texi (Fortran Compiler): Document it.
+ * tests/fortran.at (AC_FC_MODULE_FLAG): New test.
+ * tests/local.at (AT_CHECK_ENV): Do not complain about FC_MODINC
+ setting.
+ * THANKS: Update.
+
+2011-03-06 Luc Maisonobe ...
Alexander Pletzer ...
Ralf Wildenhues ...
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index f3a87d1..65fb9bb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8378,6 +8378,51 @@ Fortran Compiler
@code{ac_cv_fc_module_ext} variable.
@end defmac
+@defmac AC_FC_MODULE_FLAG (@ovar{action-if-sucess}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@acindex{FC_MODULE_FLAG}
+@caindex fc_module_flag
+@ovindex FC_MODINC
+@ovindex ac_empty
+
+Find the compiler flag to include Fortran 90 module information from
+another directory, and store that in the @code{FC_MODINC} variable.
+Call @var{action-if-success} (defaults to nothing) if successful, and
+set @code{FC_MODINC} to empty and call @var{action-if-failure} (defaults
+to exiting with an error message) if not.
+
+Most Fortran 90 compilers provide a way to specify module directories.
+Some have separate flags for the directory to write module files to,
+and directories to search them in, whereas others only allow writing to
+the current directory or to the first directory specified in the include
+path. Further, with some compilers, the module search path and the
+preprocessor search path can only be modified with the same flag. Thus,
+for portability, write module files to the current directory only and
+list that as first directory in the search path.
+
+There may be no whitespace between @code{FC_MODINC} and the following
+directory name, but @code{FC_MODINC} may contain trailing white space.
+For example, if you use Automake and would like to search @file{../lib}
+for module files, you can use the following:
+
+@example
+AM_FCFLAGS = $(FC_MODINC). $(FC_MODINC)../lib
+@end example
+
+Inside @command{configure} tests, you can use:
+
+@example
+if test -n $FC_MODINC; then
+ FCFLAGS=$FCFLAGS $FC_MODINC. $FC_MODINC../lib
+fi
+@end example
+
+The flag is cached in the @code{ac_cv_fc_module_flag} variable.
+The substituted value of @code{FC_MODINC} may refer to the
+@code{ac_empty} dummy placeholder empty variable, to avoid losing
+the significant trailing whitespace in a @file{Makefile}.
+@end defmac
+
@node Go Compiler
@subsection Go Compiler Characteristics
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 864fcaa..b03af38 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1559,3 +1559,78 @@ if test $FC_MODEXT = unknown; then
fi
AC_SUBST([FC_MODEXT])dnl
])
+
+
+# AC_FC_MODULE_FLAG([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+# -
+# Find a flag to include Fortran 90 modules from another directory.
+# If successful, run ACTION-IF-SUCCESS (defaults to nothing), otherwise
+# run ACTION-IF-FAILURE (defaults to failing with an error message).
+# The module flag is cached in the ac_cv_fc_module_flag variable.
+# It may contain significant trailing whitespace.
+#
+# Known flags:
+# gfortran: -Idir, -I dir (-M dir (deprecated), -Jdir for writing)
+# g95: -I dir (-fmod=dir for writing)
+# SUN: -Mdir, -M dir (-moddir=dir for writing;
+# -Idir for includes is also searched)
+# HP: -Idir, -I dir (+moddir=dir for writing)
+# IBM: -Idir (-qmoddir=dir for writing)
+# Absoft: -pdir
+# Lahey: -mod dir
+# Cray: -module dir, -p dir (-J dir for writing)
+# -e m is needed to enable writing .mod files at all
+# Compaq: -Idir
+# NAGWare: -I
Re: AC_FC_CHECK_BOUNDS for Fortran array bounds checking.
* Eric Blake wrote on Tue, Mar 01, 2011 at 08:53:02PM CET:
On 02/27/2011 09:10 AM, Ralf Wildenhues wrote:
here's a first macro to improve Fortran support in Autoconf.
It uses Fortran 90 interface declarations, so a F77 version
would have to be different (and I'm not quite sure whether
this works as well in Fortran 77). I only have access to a
few of the listed compilers, the other flags are taken from
manuals only. I gather fixes will come from users over time.
OK to push? Eve-Marie, OK to add your name and email to THANKS?
OK from my end, after addressing a nit. In fact, since you are much
more familiar with Fortran than I am, I'm comfortable with you pushing
all of your recent Fortran patches if you don't get any better review
within a few days.
Here we go with an updated patch, which I will push in a minute.
I've addressed your nits, omitted the THANKS update for now (pending
feedback from Eve-Marie), added a few more compilers, and reordered and
reformatted the NEWS entry (in the face of other patches to come).
I also documented the Fortran 90 requirement and the cache variable name
in the manual.
A AC_F77_CHECK_BOUNDS macro would be nice eventually.
Thanks,
Ralf
New macro AC_FC_CHECK_BOUNDS to enable Fortran array bounds checking.
* lib/autoconf/fortran.m4 (AC_FC_CHECK_BOUNDS): New macro.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/fortran.at (AC_FC_CHECK_BOUNDS): New test.
* NEWS: Update.
Prompted by report from Eve-Marie Devaliere.
diff --git a/NEWS b/NEWS
index 3edebd8..0e36b87 100644
--- a/NEWS
+++ b/NEWS
@@ -12,6 +12,10 @@ GNU Autoconf NEWS - User visible changes.
- New macro AC_HEADER_CHECK_STDBOOL.
+- New and updated macros for Fortran support:
+
+AC_FC_CHECK_BOUNDS to enable array bounds checking
+
* Noteworthy changes in release 2.68 (2010-09-22) [stable]
Released by Eric Blake, based on git versions 2.67.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 5fc9ffe..e6ff3ec 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8248,6 +8248,20 @@ Fortran Compiler
message).
@end defmac
+@defmac AC_FC_CHECK_BOUNDS (@ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@acindex{FC_CHECK_BOUNDS}
+
+The @code{AC_FC_CHECK_BOUNDS} macro tries to enable array bounds checking
+in the Fortran compiler. If successful, the @var{action-if-success}
+is called and any needed flags are added to @code{FCFLAGS}. Otherwise,
+@var{action-if-failure} is called, which defaults to failing with an error
+message. The macro currently requires Fortran 90 or a newer dialect.
+
+The result of the macro is cached in the @code{ac_cv_fc_check_bounds}
+variable.
+@end defmac
+
@node Go Compiler
@subsection Go Compiler Characteristics
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 30544c4..180fc6d 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1367,3 +1367,82 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_LINE_LENGTH
+
+
+# AC_FC_CHECK_BOUNDS([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+# --
+# Look for a compiler flag to turn on array bounds checking for the
+# Fortran (FC) compiler, and adds it to FCFLAGS. Call
+# ACTION-IF-SUCCESS (defaults to nothing) if successful (i.e. can
+# compile code using new extension) and ACTION-IF-FAILURE (defaults to
+# failing with an error message) if not. (Defined via DEFUN_ONCE to
+# prevent flag from being added to FCFLAGS multiple times.)
+#
+# The known flags are:
+# -fcheck=all, -fbounds-check: gfortran
+# -fbounds-check: g77, g95
+# -CB, -check bounds: Intel compiler (icc, ecc, ifort)
+# -C: Sun/Oracle compiler (f95)
+#-C, -qcheck: IBM compiler (xlf)
+# -Mbounds: Portland Group compiler
+# -C ,-Mbounds: Cray
+# -C, -check_bounds: SGI compiler
+# -check_bounds, +check=all: HP Fortran
+#-C, -Rb -Rc: Absoft (-Rb: array boundaries, -Rc: array conformance)
+# --chk e,s -chk (e,s): Lahey
+# -C -C=all: NAGWare
+# -C, -ffortran-bounds-check: PathScale pathf90
+# -C: f2c
+#-BOunds: Open Watcom
+AC_DEFUN_ONCE([AC_FC_CHECK_BOUNDS],
+[AC_LANG_PUSH([Fortran])dnl
+AC_CACHE_CHECK([for Fortran flag to enable array-bounds checking],
+ [ac_cv_fc_check_bounds],
+[ac_cv_fc_check_bounds=unknown
+ac_fc_check_bounds_FCFLAGS_save=$FCFLAGS
+for ac_flag in -fcheck=bounds -fbounds-check -check_bounds -Mbounds -qcheck \
+ '-check bounds' +check=all --check '-Rb -Rc' -CB -C=all -C \
+ -ffortran-bounds-check --chk e,s -chk e -chk s -bounds
+do
+ FCFLAGS=$ac_fc_check_bounds_FCFLAGS_save $ac_flag
+ # We should be able to link a correct program.
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
+[AC_LINK_IFELSE([[
+ subroutine sub(a)
+ integer a(:)
+ a(8) = 0
+ end subroutine
+
+ program main
Re: New macro AC_FC_IMPLICIT_NONE to disable Fortran implicit int.
* Eric Blake wrote on Tue, Mar 01, 2011 at 08:54:50PM CET:
On 02/27/2011 09:18 AM, Ralf Wildenhues wrote:
Another fairly simple Fortran macro, with data gathered from manuals
and from the overview site which Eve-Marie linked to.
Same comments as the last patch, including:
+@defmac AC_FC_IMPLICIT_NONE (@ovar{action-if-success},
@ovar{action-if-failure})
should this use @dvar{action-if-failure, AC_MSG_FAILURE}?
Yes, thanks.
This is one of the macros that is not only useful for Fortran 77, but
also easy to port (as the code is already Fortran 77). So I went ahead
and factored it into AC_{F77,FC}_IMPLICIT_NONE.
I also fixed the autoconf.texi entry to not end up on the section about
Go. Added switches for a few more compilers. Added a print use of the
variable to avoid warnings about unused variables (given sufficient
warning flags; thanks Tobias for the hint!).
I then noted that Intel ifort only warns but doesn't fail upon implicit
declarations. Gah! This compiler is really not easy to support: with
unknown command-line arguments, it only warns but does not fail. On the
upside, it has a somewhat elaborate set of flags to turn warnings into
errors '-warn errors' (mind you, it then still doesn't fail over unknown
command-line args) , but on the downside the machinery seems quite buggy
in that for example, adding '-warn stderrors' (which aims to _also_ warn
about standard-conformance errors) turns the exit status back into zero.
Command-line order does not matter. :-(
Since I'm not yet ready to get into the business of heuristically
comparing warning output from compilers, the macro tries both -u and
'-u -warn errors', in the hope that the user hasn't turned on other
warning flags yet.
Thanks for reading this far. Will push this in a minute.
Cheers,
Ralf
New macros AC_{F77,FC}_IMPLICIT_NONE to disable Fortran implicit int.
* lib/autoconf/fortran.m4 (_AC_FC_IMPLICIT_NONE): New internal
macro.
(AC_F77_IMPLICIT_NONE, AC_FC_IMPLICIT_NONE): New macros.
* doc/autoconf.texi (Fortran Compiler): Document them.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index 0e36b87..6a1771d 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,7 @@ GNU Autoconf NEWS - User visible changes.
- New and updated macros for Fortran support:
AC_FC_CHECK_BOUNDS to enable array bounds checking
+AC_F77_IMPLICIT_NONE and AC_FC_IMPLICIT_NONE to disable implicit integer
* Noteworthy changes in release 2.68 (2010-09-22) [stable]
Released by Eric Blake, based on git versions 2.67.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index e9bd85d..273fa60 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8259,6 +8259,19 @@ Fortran Compiler
message.
@end defmac
+@defmac AC_F77_IMPLICIT_NONE (@ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@defmacx AC_FC_IMPLICIT_NONE (@ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@acindex{F77_IMPLICIT_NONE}
+@acindex{FC_IMPLICIT_NONE}
+
+Try to disallow implicit declarations in the Fortran compiler. If
+successful, the @var{action-if-success} is called and any needed flags
+are added to @code{FCFLAGS}. Otherwise, @var{action-if-failure} is
+called, which defaults to failing with an error message.
+@end defmac
+
@node Go Compiler
@subsection Go Compiler Characteristics
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 180fc6d..14e1c9c 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1446,3 +1446,75 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_CHECK_BOUNDS
+
+
+# _AC_FC_IMPLICIT_NONE([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+#
+# Look for a flag to disallow implicit declarations, and add it to FCFLAGS.
+# Call ACTION-IF-SUCCESS (defaults to nothing) if successful and
+# ACTION-IF-FAILURE (defaults to failing with an error message) if not.
+#
+# Known flags:
+# GNU gfortran, g95: -fimplicit-none, g77: -Wimplicit
+# Intel: -u, -implicitnone; might also need '-warn errors' to turn into error.
+# Sun/Oracle: -u
+# HP: +implicit_none
+# IBM: -u, -qundef
+# SGI: -u
+# Compaq: -u, -warn declarations
+# NAGWare: -u
+# Lahey: -in, --in, -AT
+# Cray: -Mdclchk -d i
+# PGI: -Mcdlchk
+# f2c: -u
+AC_DEFUN([_AC_FC_IMPLICIT_NONE],
+[_AC_FORTRAN_ASSERT()dnl
+AC_CACHE_CHECK([for flag to disallow _AC_LANG implicit declarations],
+ [ac_cv_[]_AC_LANG_ABBREV[]_implicit_none],
+[ac_cv_[]_AC_LANG_ABBREV[]_implicit_none=unknown
+ac_fc_implicit_none_[]_AC_LANG_PREFIX[]FLAGS_save=$[]_AC_LANG_PREFIX[]FLAGS
+for ac_flag in none -fimplicit-none -u -Wimplicit -implicitnone +implicit_none
\
+ -qundef -warn declarations -in --in -AT -d i -Mdclchk \
+ -u -warn errors
+do
+ if test x$ac_flag != xnone; then
+_AC_LANG_PREFIX[]FLAGS=$ac_fc_implicit_none_[]_AC_LANG_PREFIX[]FLAGS_save
$ac_flag
+ fi
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM
AC_FC_SRCEXT: allow gfortran to compile .f77 files.
While the .f77 extension is not supported by all Fortran compilers, it is documented by some, we already test it in the AC_FC_SRCEXT usage test, and when we can get more compilers to accept it, that can only be helpful. I'm pushing the patch below to get gfortran to accept this extension. Thanks, Ralf AC_FC_SRCEXT: allow gfortran to compile .f77 files. * lib/autoconf/fortran.m4 (AC_FC_SRCEXT): Try '-x f77' for .f77 files, '-x f95' for others, for gfortran. diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index 14e1c9c..237cdd9 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/fortran.m4 @@ -1137,6 +1137,8 @@ AC_LANG_POP(Fortran)dnl # Also, for Intel's ifc compiler (which does not accept .f95 by default in # some versions), the $FCFLAGS_EXT variable *must* go immediately before # the source file on the command line, unlike other $FCFLAGS. Ugh. +# +# gfortran requires '-x f77' in order to recognize .f77 files. AC_DEFUN([AC_FC_SRCEXT], [AC_LANG_PUSH(Fortran)dnl AC_CACHE_CHECK([for Fortran flag to compile .$1 files], @@ -1145,7 +1147,11 @@ AC_CACHE_CHECK([for Fortran flag to compile .$1 files], ac_fcflags_srcext_save=$ac_fcflags_srcext ac_fcflags_srcext= ac_cv_fc_srcext_$1=unknown -for ac_flag in none -qsuffix=f=$1 -Tf; do +case $ac_ext in #( + [[fF]]77) ac_try=f77;; #( + *) ac_try=f95;; +esac +for ac_flag in none -qsuffix=f=$1 -Tf -x $ac_try; do test x$ac_flag != xnone ac_fcflags_srcext=$ac_flag AC_COMPILE_IFELSE([AC_LANG_PROGRAM()], [ac_cv_fc_srcext_$1=$ac_flag; break]) done
Re: New macro AC_FC_IMPLICIT_NONE to disable Fortran implicit int.
* Ralf Wildenhues wrote on Sat, Mar 05, 2011 at 09:37:55AM CET:
New macros AC_{F77,FC}_IMPLICIT_NONE to disable Fortran implicit int.
* lib/autoconf/fortran.m4 (_AC_FC_IMPLICIT_NONE): New internal
macro.
(AC_F77_IMPLICIT_NONE, AC_FC_IMPLICIT_NONE): New macros.
* doc/autoconf.texi (Fortran Compiler): Document them.
* NEWS: Update.
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8259,6 +8259,19 @@ Fortran Compiler
message.
@end defmac
+@defmac AC_F77_IMPLICIT_NONE (@ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@defmacx AC_FC_IMPLICIT_NONE (@ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
+@acindex{F77_IMPLICIT_NONE}
+@acindex{FC_IMPLICIT_NONE}
+
+Try to disallow implicit declarations in the Fortran compiler. If
+successful, the @var{action-if-success} is called and any needed flags
+are added to @code{FCFLAGS}. Otherwise, @var{action-if-failure} is
+called, which defaults to failing with an error message.
+@end defmac
Gah, I managed to both post an outdated diff which lacked the cache
variable documentation, and to forget mentioning FFLAGS. Here's how
the text looks now, after fixing it up:
Try to disallow implicit declarations in the Fortran compiler. If
successful, @var{action-if-success} is called and any needed flags
are added to @code{FFLAGS} or @code{FCFLAGS}, respectively. Otherwise,
@var{action-if-failure} is called, which defaults to failing with an error
message.
The result of these macros are cached in the
@code{ac_cv_f77_implicit_none} and @code{ac_cv_fc_implicit_none}
variables, respectively.
Sorry about that,
Ralf
docs: document several Fortran and OpenMP cache variables.
I went ahead and documented a bunch of cache variables, as below.
The only one I think looks kinda odd in hindsight is
ac_cv_prog_c_openmp, as all other ac_cv_prog_* cache variables that deal
with the C compiler use cc not c as key.
Thanks,
Ralf
docs: document several Fortran and OpenMP cache variables.
* doc/autoconf.texi (Generic Compiler Characteristics)
[AC_OPENMP]: Document associated cache variables.
(Fortran Compiler) [AC_PROG_F77, AC_PROG_FC, AC_PROG_F77_C_O]
[AC_PROG_FC_C_O, AC_F77_LIBRARY_LDFLAGS, AC_FC_LIBRARY_LDFLAGS]
[AC_F77_DUMMY_MAIN, AC_FC_DUMMY_MAIN, AC_F77_MAIN, AC_FC_MAIN]
[AC_F77_WRAPPERS, AC_FC_WRAPPERS, AC_FC_FREEFORM]
[AC_FC_FIXEDFORM, AC_FC_LINE_LENGTH, AC_FC_CHECK_BOUNDS]
[AC_F77_IMPLICIT_NONE, AC_FC_IMPLICIT_NONE]: Document and/or
index the cache variables used by these macros.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1cd246b..b552883 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7112,6 +7112,10 @@ Generic Compiler Characteristics
@ovindex OPENMP_CXXFLAGS
@ovindex OPENMP_FFLAGS
@ovindex OPENMP_FCFLAGS
+@caindex prog_c_openmp
+@caindex prog_cxx_openmp
+@caindex prog_f77_openmp
+@caindex prog_fc_openmp
@uref{http://@/www.openmp.org/, OpenMP} specifies extensions of C, C++,
and Fortran that simplify optimization of shared memory parallelism,
which is a common problem on multicore CPUs.
@@ -7149,6 +7153,10 @@ Generic Compiler Characteristics
@samp{pragma omp}. That is, write @samp{#pragma omp}, not
@samp{# pragma omp}. The Sun WorkShop 6.2 C compiler chokes on the
latter.
+
+This macro caches its result in the @code{ac_cv_prog_c_openmp},
+@code{ac_cv_prog_cxx_openmp}, @code{ac_cv_prog_f77_openmp}, or
+@code{ac_cv_prog_fc_openmp} variable, depending on the current language.
@end defmac
@node C Compiler
@@ -7858,6 +7866,8 @@ Fortran Compiler
@evindex FFLAGS
@ovindex F77
@ovindex FFLAGS
+@caindex f77_compiler_gnu
+@caindex prog_f77_g
Determine a Fortran 77 compiler to use. If @code{F77} is not already
set in the environment, then check for @code{g77} and @code{f77}, and
then some other names. Set the output variable @code{F77} to the name
@@ -7880,6 +7890,10 @@ Fortran Compiler
environment, then set it to @option{-g -02} for @code{g77} (or @option{-O2}
where @code{g77} does not accept @option{-g}). Otherwise, set
@code{FFLAGS} to @option{-g} for all other Fortran 77 compilers.
+
+The result of the GNU test is cached in the
+@code{ac_cv_f77_compiler_gnu} variable, acceptance of @option{-g} in the
+@code{ac_cv_prog_f77_g} variable.
@end defmac
@defmac AC_PROG_FC (@ovar{compiler-search-list}, @ovar{dialect})
@@ -7888,6 +7902,8 @@ Fortran Compiler
@evindex FCFLAGS
@ovindex FC
@ovindex FCFLAGS
+@caindex fc_compiler_gnu
+@caindex prog_fc_g
Determine a Fortran compiler to use. If @code{FC} is not already set in
the environment, then @code{dialect} is a hint to indicate what Fortran
dialect to search for; the default is to search for the newest available
@@ -7912,6 +7928,10 @@ Fortran Compiler
environment, then set it to @option{-g -02} for GNU @code{g77} (or
@option{-O2} where @code{g77} does not accept @option{-g}). Otherwise,
set @code{FCFLAGS} to @option{-g} for all other Fortran compilers.
+
+The result of the GNU test is cached in the @code{ac_cv_fc_compiler_gnu}
+variable, acceptance of @option{-g} in the @code{ac_cv_prog_fc_g}
+variable.
@end defmac
@defmac AC_PROG_F77_C_O
@@ -7920,9 +7940,14 @@ Fortran Compiler
@acindex{PROG_FC_C_O}
@cvindex F77_NO_MINUS_C_MINUS_O
@cvindex FC_NO_MINUS_C_MINUS_O
+@caindex prog_f77_c_o
+@caindex prog_fc_c_o
Test whether the Fortran compiler accepts the options @option{-c} and
@option{-o} simultaneously, and define @code{F77_NO_MINUS_C_MINUS_O} or
@code{FC_NO_MINUS_C_MINUS_O}, respectively, if it does not.
+
+The result of the test is cached in the @code{ac_cv_prog_f77_c_o} or
+@code{ac_cv_prog_fc_c_o} variable, respectively.
@end defmac
The following macros check for Fortran compiler characteristics.
@@ -7939,6 +7964,10 @@ Fortran Compiler
@ovindex FLIBS
@acindex{FC_LIBRARY_LDFLAGS}
@ovindex FCLIBS
+@caindex prog_f77_v
+@caindex prog_fc_v
+@caindex f77_libs
+@caindex fc_libs
Determine the linker flags (e.g., @option{-L} and @option{-l}) for the
@dfn{Fortran intrinsic and runtime libraries} that are required to
successfully link a Fortran program or shared library. The output
@@ -7967,6 +7996,11 @@ Fortran Compiler
that you use @code{AC_CONFIG_HEADERS} (@pxref{Configuration Headers})
because the complex defines that the function wrapper macros create
may not work with C/C++ compiler drivers.
+
+These macros internally compute the flag needed to verbose linking
+output and cache it in @code{ac_cv_prog_f77_v} or @code{ac_cv_prog_fc_v}
+variables, respectively. The computed linker flags are cached in
+@code{ac_cv_f77_libs} or @code{ac_cv_fc_libs}, respectively.
@end defmac
@defmac AC_F77_DUMMY_MAIN
Re: New macro AC_FC_IMPLICIT_NONE to disable Fortran implicit int.
* Ralf Wildenhues wrote on Sat, Mar 05, 2011 at 09:37:55AM CET:
New macros AC_{F77,FC}_IMPLICIT_NONE to disable Fortran implicit int.
* lib/autoconf/fortran.m4 (_AC_FC_IMPLICIT_NONE): New internal
macro.
(AC_F77_IMPLICIT_NONE, AC_FC_IMPLICIT_NONE): New macros.
* doc/autoconf.texi (Fortran Compiler): Document them.
* NEWS: Update.
First bugfix patch. Pushing as below, adding Tobias to THANKS.
Thanks,
Ralf
Fix Cray Fortran flag for AC_FC_IMPLICIT_NONE.
* lib/autoconf/fortran.m4 (_AC_FC_IMPLICIT_NONE): Use -e I
not -d i, for Cray ftn.
* THANKS: Update.
Thanks to Tobias Burnus for feedback and testing.
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 237cdd9..84f3162 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1470,7 +1470,7 @@ AC_LANG_POP([Fortran])dnl
# Compaq: -u, -warn declarations
# NAGWare: -u
# Lahey: -in, --in, -AT
-# Cray: -Mdclchk -d i
+# Cray: -Mdclchk -e I
# PGI: -Mcdlchk
# f2c: -u
AC_DEFUN([_AC_FC_IMPLICIT_NONE],
@@ -1480,7 +1480,7 @@ AC_CACHE_CHECK([for flag to disallow _AC_LANG implicit
declarations],
[ac_cv_[]_AC_LANG_ABBREV[]_implicit_none=unknown
ac_fc_implicit_none_[]_AC_LANG_PREFIX[]FLAGS_save=$[]_AC_LANG_PREFIX[]FLAGS
for ac_flag in none -fimplicit-none -u -Wimplicit -implicitnone +implicit_none
\
- -qundef -warn declarations -in --in -AT -d i -Mdclchk \
+ -qundef -warn declarations -in --in -AT -e I -Mdclchk \
-u -warn errors
do
if test x$ac_flag != xnone; then
Re: docs: document several Fortran and OpenMP cache variables.
Hello Paul, * Paul Eggert wrote on Sat, Mar 05, 2011 at 06:13:54PM CET: On 03/05/2011 08:35 AM, Ralf Wildenhues wrote: The only one I think looks kinda odd in hindsight is ac_cv_prog_c_openmp How about if we rename that to ac_cv_prog_cc_openmp, then? Might as well do it now, before it escapes. Sorry, I obviously totally failed to convey the point, as I forgot half of the issue. AC_OPENMP correctly uses _AC_LANG_ABBREV to set the language part of the cache variable name. For C, that is defined as 'c' as per the AC_LANG_DEFINE call in c.m4. It's just that most of the other ac_cv_prog_* cache variables that deal with C compiler issues use cc rather than _AC_LANG_ABBREV. So, that macro is actually correct, technically. Just looks a bit weird when looking at the cache variable index. The other cache variables have been used (and documented) for a longer time, so I don't think it's a good idea to rename just for the sake of consistency. Thanks, Ralf
New macro AC_FC_PP_SRCEXT for preprocessed file extensions.
Fortran and preprocessing is another long story, not even starting with
COCO.
Of those Fortran 90+ compilers that I can get hold of, all provide some
way or another to enable preprocessing of source files with all kinds of
file name extensions. It just isn't easy sometimes (esp. older gfortran
took some searching). Just like in the AC_FC_SRCEXT case, the most
general case is that you need a different flag per file name extension
(thanks to IBM).
I'm guessing that it is possible to go with a minimal common denominator
of only using .F (not even .F90 is universal if I read the Sun manual
correctly), but relying on case-sensitive file systems is not cool and
telling other developers to mass-rename their files does not get you
high karma either.
So, here's what I came up with. The macro is the sister of AC_FC_SRCEXT
and you can just replace its usage in projects where you want files to
be preprocessed. In projects where it is *necessary* to disable the
preprocessor for some files with the same suffixes, I suppose you can
still play games with configure cache variables and manually written
makefile rules again; but other than that, I suppose Automake can
support all of this seamlessly eventually. (Meanwhile, overriding the
respective inference rules is fairly straightforward, see below.)
I'm unsure about the macro name. AC_FC_PP_SRCEXT or AC_FCPP_SRCEXT?
Or maybe AC_FC_CPP_SRCEXT? Or preprocessing as additional optional
argument for AC_FC_SRCEXT?
Another thing I'm not totally sure of is: should AC_FC_SRCEXT semantics
be modified to try to explicitly turn off preprocessing? Seems a bit
risky. (Or yet another macro AC_FC_NO_PP_SRCEXT or tri-state option?)
Of course, good support for preprocessed Fortran should also have a
macro to select the preprocessor, only run that, etc. Actually, that
turned out to be quite a mine field: while you can often pass some set
of options (a la -traditional-cpp -C -P) to cpp to make it behave with
Fortran code, it would be nicer to actually make use of whatever the
$FC compiler calls out to, if possible (if only to use the same spelling
of -D or -WF,-D arguments). Now, several compilers provide a -P flag to
only preprocess, but then they save the output in a file, rather than
using stdout. :-/
In projects so far, I've used either the proposed macro below, or
something like this as workaround:
# Treat all .f90 files as preprocessed Fortran.
.f90.o:
$(FCCPP) $(FCDEFS) $(FCDEFAULT_INCLUDES) $(AM_FCCPPFLAGS) $(FCCPPFLAGS)
$ $*.pp.f90
$(FCCOMPILE) -c -o $@ $(FCFLAGS_f90) $*.pp.f90
and set FCCPP to some combination of fpp or cpp and flags. I'm not sure
whether portability would in the end require going this way for some
older compilers.
Further, I'm not sure how big semantic differences between preprocessors
are, or whether we need to expose preference fpp vs cpp to the user.
I've seen flags as to whether macros are also replaced outside of lines
starting with '#'. Might be good to document a minimal common
denominator...
I haven't pushed this patch yet; I'd really appreciate some comments.
Thanks,
Ralf
New macro AC_FC_PP_SRCEXT for preprocessed file extensions.
* lib/autoconf/fortran.m4 (AC_FC_PP_SRCEXT): New macro.
* lib/autom4te.in (Automake-preselections): Preselect it.
* doc/autoconf.texi (Fortran Compiler): Document it, rewriting
the documentation for AC_FC_SRCEXT along the way.
* tests/fortran.at (AC_FC_PP_SRCEXT usage): New test.
* tests/mktests.sh: Exclude the macro from default testing.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index 6a1771d..ccf6bf2 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,7 @@ GNU Autoconf NEWS - User visible changes.
AC_FC_CHECK_BOUNDS to enable array bounds checking
AC_F77_IMPLICIT_NONE and AC_FC_IMPLICIT_NONE to disable implicit integer
+AC_FC_PP_SRCEXT for preprocessed Fortran source files extensions
* Noteworthy changes in release 2.68 (2010-09-22) [stable]
Released by Eric Blake, based on git versions 2.67.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b552883..f980d29 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8193,47 +8193,68 @@ Fortran Compiler
@defmac AC_FC_SRCEXT (@var{ext}, @ovar{action-if-success}, @
@dvar{action-if-failure, AC_MSG_FAILURE})
+@defmacx AC_FC_PP_SRCEXT (@var{ext}, @ovar{action-if-success}, @
+ @dvar{action-if-failure, AC_MSG_FAILURE})
@acindex{FC_SRCEXT}
+@acindex{FC_PP_SRCEXT}
+@caindex fc_srcext_@var{ext}
+@caindex fc_pp_srcext_@var{ext}
By default, the @code{FC} macros perform their tests using a @file{.f}
extension for source-code files. Some compilers, however, only enable
newer language features for appropriately named files, e.g., Fortran 90
-features only for @file{.f90} files. On the other hand, some other
-compilers expect all source files to end in @file{.f} and require
-special flags to support other file name extensions. The
-@code{AC_FC_SRCEXT} macro deals with both of
Re: fort77(f2c wrapper) is not properly detected
* Giulio Paci wrote on Tue, Dec 07, 2010 at 01:43:15AM CET: Il 05/12/2010 22:19, Ralf Wildenhues ha scritto: Output changes from: Fortran low level compiling/preprocessing macros. 303: GNU Fortran 77 FAILED (fortran.at:31) 304: GNU Fortran ok [...] To: Fortran low level compiling/preprocessing macros. 303: GNU Fortran 77 FAILED (fortran.at:31) 304: GNU Fortran ok This was still missing from a testsuite run with f2c wrapper fort77 fully passing. The patch below corrects that. OK to push? Thanks, Ralf 2011-03-04 Ralf Wildenhues ralf.wildenh...@gmx.de * tests/fortran.at (GNU Fortran 77): Try to detect f2c wrapper fort77 as GNU as well: it defines __GNUC__ too. Fixes testsuite failure when f77 is fort77. Report from Giulio Paci. diff --git a/tests/fortran.at b/tests/fortran.at index 741525e..4639a3a 100644 --- a/tests/fortran.at +++ b/tests/fortran.at @@ -32,17 +32,19 @@ AT_CHECK_MACRO([GNU Fortran 77], [[AC_LANG(Fortran 77) AC_LANG_COMPILER -if AC_TRY_COMMAND([$F77 --version | grep GNU 2]); then +: conftest.f +if AC_TRY_COMMAND([$F77 --version | grep GNU 2]) \ + || AC_TRY_COMMAND([$F77 -v -c conftest.f 21 | grep f2c 2]); then # Be sure to remove files which might be created by compilers that - # don't support --version. - rm -f a.exe a.out + # don't support --version, or by the second compile. + rm -f a.exe a.out conftest.f conftest.$ac_objext # Has GNU in --version. test $G77 != yes AC_MSG_ERROR([failed to recognize GNU Fortran 77 compiler]) else # Be sure to remove files which might be created by compilers that - # don't support --version. - rm -f a.exe a.out + # don't support --version, or by the second compile. + rm -f a.exe a.out conftest.f conftest.$ac_objext # Has not. test $G77 = yes AC_MSG_ERROR([incorrectly recognized a GNU Fortran 77 compiler])
docs: macro synopses document default failure cases. (was: AC_FC_CHECK_BOUNDS for Fortran array bounds checking.)
* Eric Blake wrote on Tue, Mar 01, 2011 at 08:53:02PM CET:
On 02/27/2011 09:10 AM, Ralf Wildenhues wrote:
here's a first macro to improve Fortran support in Autoconf.
OK to push? Eve-Marie, OK to add your name and email to THANKS?
OK from my end, after addressing a nit. In fact, since you are much
more familiar with Fortran than I am, I'm comfortable with you pushing
all of your recent Fortran patches if you don't get any better review
within a few days.
Thanks. I will do so. I have roughly a dozen new macros for Fortran
(some in mind, some done, some in between).
+++ b/doc/autoconf.texi
@@ -8246,6 +8246,16 @@ Fortran Compiler
message).
@end defmac
+@defmac AC_FC_CHECK_BOUNDS (@ovar{action-if-success},
@ovar{action-if-failure})
Should this be listed as @dvar{action-if-failure, AC_MSG_FAILURE}...
Yes. In fact, let's add this to other places in the manual where it is
missing. I'm pushing the patch below as obvious, together with some of
the other recently posted patches. The AC_FC_CHECK_BOUNDS one will come
shortly too.
Thanks,
Ralf
docs: macro synopses document default failure cases.
* doc/autoconf.texi (Fortran Compiler, Obsolete Macros):
Document failure case for AC_F77_DUMMY_MAIN, AC_FC_DUMMY_MAIN,
AC_FC_SRCEXT, AC_FC_FREEFORM, AC_FC_FIXEDFORM,
AC_FC_LINE_LENGTH, and AC_TRY_RUN macros.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 557d763..5fc9ffe 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7969,8 +7969,10 @@ Fortran Compiler
may not work with C/C++ compiler drivers.
@end defmac
-@defmac AC_F77_DUMMY_MAIN (@ovar{action-if-found}, @ovar{action-if-not-found})
-@defmacx AC_FC_DUMMY_MAIN (@ovar{action-if-found}, @ovar{action-if-not-found})
+@defmac AC_F77_DUMMY_MAIN (@ovar{action-if-found}, @dvar{action-if-not-found, @
+ AC_MSG_FAILURE})
+@defmacx AC_FC_DUMMY_MAIN (@ovar{action-if-found}, @dvar{action-if-not-found, @
+ AC_MSG_FAILURE})
@acindex{F77_DUMMY_MAIN}
@cvindex F77_DUMMY_MAIN
@acindex{FC_DUMMY_MAIN}
@@ -8140,7 +8142,7 @@ Fortran Compiler
@end defmac
@defmac AC_FC_SRCEXT (@var{ext}, @ovar{action-if-success}, @
- @ovar{action-if-failure})
+ @dvar{action-if-failure, AC_MSG_FAILURE})
@acindex{FC_SRCEXT}
By default, the @code{FC} macros perform their tests using a @file{.f}
extension for source-code files. Some compilers, however, only enable
@@ -8184,7 +8186,8 @@ Fortran Compiler
@end defmac
-@defmac AC_FC_FREEFORM (@ovar{action-if-success}, @ovar{action-if-failure})
+@defmac AC_FC_FREEFORM (@ovar{action-if-success}, @dvar{action-if-failure, @
+ AC_MSG_FAILURE})
@acindex{FC_FREEFORM}
Try to ensure that the Fortran compiler (@code{$FC}) allows free-format
@@ -8206,7 +8209,8 @@ Fortran Compiler
message).
@end defmac
-@defmac AC_FC_FIXEDFORM (@ovar{action-if-success}, @ovar{action-if-failure})
+@defmac AC_FC_FIXEDFORM (@ovar{action-if-success}, @dvar{action-if-failure, @
+ AC_MSG_FAILURE})
@acindex{FC_FIXEDFORM}
Try to ensure that the Fortran compiler (@code{$FC}) allows the old
@@ -8228,7 +8232,7 @@ Fortran Compiler
@end defmac
@defmac AC_FC_LINE_LENGTH (@ovar{length}, @ovar{action-if-success}, @
- @ovar{action-if-failure})
+ @dvar{action-if-failure, AC_MSG_FAILURE})
@acindex{FC_LINE_LENGTH}
Try to ensure that the Fortran compiler (@code{$FC}) accepts long source
@@ -23281,7 +23285,7 @@ Obsolete Macros
@end defmac
@defmac AC_TRY_RUN (@var{program}, @ovar{action-if-true}, @
- @ovar{action-if-false}, @ovar{action-if-cross-compiling})
+ @ovar{action-if-false}, @dvar{action-if-cross-compiling, AC_MSG_FAILURE})
@acindex{TRY_RUN}
Same as:
Update known compiler switches for Fortran and OpenMP macros.
This patch is my current known set of updates for existing Fortran macros. Most of the switches are taken from manuals only (I don't really have access to that many compilers), so there might still be bugs. I plan to ask a couple of people with other Fortran compilers once my patch queue is fairly flushed; it is simpler to just fix all fallout at once then. When some compiler lists more than just one flag, that might be due to different versions of the compiler, or to just alternate spellings. Since the latter often results from the former, I typically chose to try all variants. The Lahey single and double dash flags are for w32 and GNU/Linux, respectively (at least that is what the manuals imply). I'm pushing this, as indicated by Eric, although of course I always welcome any review. Thanks, Ralf Update known compiler switches for Fortran and OpenMP macros. * lib/autoconf/c.m4 (AC_OPENMP): Update for Lahey on GNU/Linux. * lib/autoconf/fortran.m4 (_AC_F95_FC): Also try nagfor. (_AC_PROG_FC_V): Update documentation for Lahey switches. (AC_FC_FREEFORM, AC_FC_FIXEDFORM): Add flags for Absoft, Lahey on GNU/Linux, document NAGWare, g95, and f2c switches. (AC_FC_LINE_LENGTH): Document NAGware switch. Update Absoft, Lahey, NAGWare, Open Watcom, g95, and f2c switches. diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4 index 89e6b49..e4b807b 100644 --- a/lib/autoconf/c.m4 +++ b/lib/autoconf/c.m4 @@ -2001,12 +2001,14 @@ AC_DEFUN([AC_OPENMP], dnl IBM C (AIX, Linux) -qsmp=omp dnl Cray CCE -homp dnl NEC SX -Popenmp + dnl Lahey Fortran (Linux) --openmp dnl If in this loop a compiler is passed an option that it doesn't dnl understand or that it misinterprets, the AC_LINK_IFELSE test dnl will fail (since we know that it failed without the option), dnl therefore the loop will continue searching for an option, and dnl no output file called 'penmp' or 'mp' is created. - for ac_option in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp -homp -Popenmp; do + for ac_option in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp -homp \ + -Popenmp --openmp; do ac_save_[]_AC_LANG_PREFIX[]FLAGS=$[]_AC_LANG_PREFIX[]FLAGS _AC_LANG_PREFIX[]FLAGS=$[]_AC_LANG_PREFIX[]FLAGS $ac_option AC_LINK_IFELSE([_AC_LANG_OPENMP], diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index d5afbb9..30544c4 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/fortran.m4 @@ -316,7 +316,8 @@ AC_DEFUN([_AC_FC_DIALECT_YEAR], # fort: Compaq (now HP) Fortran 90/95 compiler for Tru64 and Linux/Alpha # ifort, previously ifc: Intel Fortran 95 compiler for Linux/x86 # efc: Intel Fortran 95 compiler for IA64 -m4_define([_AC_F95_FC], [gfortran g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn]) +# nagfor: NAGWare Fortran 77/90/95 compiler +m4_define([_AC_F95_FC], [gfortran g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn nagfor]) m4_define([_AC_F90_FC], [xlf90 f90 pgf90 pghpf epcf90]) m4_define([_AC_F77_FC], [g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77]) AC_DEFUN([_AC_PROG_FC], @@ -564,7 +565,7 @@ esac # Determine the flag that causes the Fortran compiler to print # information of library and object files (normally -v) # Needed for _AC_FC_LIBRARY_FLAGS -# Some compilers don't accept -v (Lahey: -verbose, xlf: -V, Fujitsu: -###) +# Some compilers don't accept -v (Lahey: (-)-verbose, xlf: -V, Fujitsu: -###) AC_DEFUN([_AC_PROG_FC_V], [_AC_FORTRAN_ASSERT()dnl AC_CACHE_CHECK([how to get verbose linking output from $[]_AC_FC[]], @@ -1179,15 +1180,17 @@ AC_LANG_POP(Fortran)dnl # prevent flag from being added to FCFLAGS multiple times.) # # The known flags are: -#-ffree-form: GNU g77, gfortran +#-ffree-form: GNU g77, gfortran, g95 # -FR, -free: Intel compiler (icc, ecc, ifort) # -free: Compaq compiler (fort), Sun compiler (f95) # -qfree: IBM compiler (xlf) # -Mfree, -Mfreeform: Portland Group compiler # -freeform: SGI compiler -#-f free: Absoft Fortran +#-8, -f free: Absoft Fortran # +source=free: HP Fortran -# -nfix: Lahey/Fujitsu Fortran +#(-)-nfix, -Free: Lahey/Fujitsu Fortran +# -free: NAGWare +# -f, -Wf,-f: f2c (but only a weak form of free-form and long lines) # We try to test the more popular flags first, by some prejudiced # notion of popularity. AC_DEFUN_ONCE([AC_FC_FREEFORM], @@ -1197,7 +1200,7 @@ AC_CACHE_CHECK([for Fortran flag needed to accept free-form source], [ac_cv_fc_freeform=unknown ac_fc_freeform_FCFLAGS_save=$FCFLAGS for ac_flag in none -ffree-form -FR -free -qfree -Mfree -Mfreeform \ - -freeform -f free +source=free -nfix + -freeform -f free -8 +source=free -nfix --nfix -Free do test x$ac_flag != xnone
Re: [PATCH] Document AC_FUNC_FORK cache variables
Hello Eric,
in
http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/7500/focus=7501
I asked the following:
* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 07:57:11AM CET:
* Colin Watson wrote on Mon, Dec 20, 2010 at 12:33:46AM CET:
I maintain a package where I'd like to fail at configure time if fork
doesn't work. This is slightly awkward because 'info autoconf' doesn't
document the cache variables for AC_FUNC_FORK, so I don't know whether I
can rely on them in future versions of Autoconf. Would you be willing
to document them as follows and thereby promise that they will continue
to work?
The reason we didn't document them right away was because the semantics
are a bit more complex: while you can read the results in these
variables, you cannot override the test completely by setting these
variables. ac_cv_func_fork and ac_cv_func_vfork are also involved.
We could change the macro so that the _works variables are not
overridden when set, or just document the need to also set the
other two. Below is a (fairly untested) patch for the former
(4 new lines plus large reindent). However, this still differs
in configure output (the _works result is not communicated in the
cache case) so I'm not sure this is the better approach.
Probably easier to append In order to override the test, you also
need to set the @code{ac_cv_func_fork} and @code{ac_cv_func_vfork}
variables. Eric?
My preference would be to drop my proposed patch (see link above)
and instead push the following in Colin's name, and add him to THANKS.
Any issues with that?
Thanks,
Ralf
2011-03-04 Colin Watson ... (tiny change)
Ralf Wildenhues ...
* doc/autoconf.texi (Particular Functions): Document AC_FUNC_FORK
cache variables.
* THANKS: Update.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index e87b8b4..eea6bc7 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -5004,6 +5004,11 @@ Particular Functions
#endif
@end group
@end example
+
+The results of this macro are cached in the @code{ac_cv_func_fork_works}
+and @code{ac_cv_func_vfork_works} variables. In order to override the
+test, you also need to set the @code{ac_cv_func_fork} and
+@code{ac_cv_func_vfork} variables.
@end defmac
@defmac AC_FUNC_FSEEKO
Re: Exclude M4 with buggy strstr when configuring Autoconf.
* Eric Blake wrote on Mon, Feb 28, 2011 at 07:06:50PM CET:
On 02/26/2011 07:50 AM, Ralf Wildenhues wrote:
Autoconf's m4/m4.m4 needs a similar test.
Thanks. Like this?
Close, but I'm still thinking about it.
There's two separate strstr issues:
Thanks for the detailed explanations. That's going to be painful
though, as basically only (little-tested) 1.4.16 is the only viable
alternative, as there have been security issues fixed after 1.4.10.
I should note that it won't exclude a buggy m4 that the user has
explicitly set by setting the M4 environment variable.
Agreed. It's also possible to detect a broken strstr at runtime as part
of m4_init, although I'm not sure whether to do that yet. It's even
technically feasible to replace a broken m4_index() with m4_regex() (by
escaping the search string and doing the search via regular expressions
instead), but certainly inefficient, and I'm not sure it's worth the
hassle to try that.
It would be sad to see further runtime slowdown due to bugs in tools,
IMVHO.
Updated patch below. OK?
Thanks,
Ralf
2011-03-05 Ralf Wildenhues ralf.wildenh...@gmx.de
Eric Blake ebl...@redhat.com
Exclude M4 with buggy strstr when configuring Autoconf.
* m4/m4.m4 (AC_PROG_GNU_M4): When searching PATH, do not accept
an m4 that has either the gnulib strstr bug, or the glibc/gnulib
strstr bug.
diff --git a/m4/m4.m4 b/m4/m4.m4
index a11fe0d..e37ff4e 100644
--- a/m4/m4.m4
+++ b/m4/m4.m4
@@ -1,4 +1,4 @@
-# m4.m4 serial 11
+# m4.m4 serial 12
# Copyright (C) 2000, 2006-2011 Free Software Foundation, Inc.
@@ -25,15 +25,24 @@ AS_UNSET([POSIXLY_CORRECT])
AC_PATH_PROGS_FEATURE_CHECK([M4], [m4 gm4 gnum4],
[dnl Creative quoting here to avoid raw dnl and ifdef in configure.
# Root out GNU M4 1.4.5, as well as non-GNU m4 that ignore -t, -F.
+ # Root out GNU M4 1.4.13 and 1.4.14 with buggy replacement strstr.
+ # Root out Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 with buggy
+ # strstr.
ac_snippet=change'quote(,)in''dir(if''def,mac,bug)'
ac_snippet=${ac_snippet}pat'subst(a,\(b\)\|\(a\),\1)d'nl
+
ac_snippet=${ac_snippet}${as_nl}if'else(in''dex(..wi.d.,.d.),-1,strstr-bug)'
+ ac_snippet=${ac_snippet}${as_nl}if'else(in''dex(dnl
+;:11-:12-:12-:12-:12-:12-:12-:12-:12.:12.:12.:12.:12.:12.:12.:12.:12-,dnl
+:12-:12-:12-:12-:12-:12-:12-:12-),-1,,strstr-bug2)'
test -z `$ac_path_M4 -F conftest.m4f /dev/null 21` \
test -z `AS_ECHO([$ac_snippet]) | $ac_path_M4 --trace=mac 21` \
test -f conftest.m4f \
ac_cv_path_M4=$ac_path_M4 ac_path_M4_found=:
rm -f conftest.m4f],
[AC_MSG_ERROR([no acceptable m4 could be found in \$PATH.
-GNU M4 1.4.6 or later is required; 1.4.14 is recommended])])])
+GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
+GNU M4 1.4.14 and 1.4.15 use a buggy replacement strstr on some systems.
+Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug])])])
M4=$ac_cv_path_M4
AC_CACHE_CHECK([whether $ac_cv_path_M4 accepts --gnu],
[ac_cv_prog_gnu_m4_gnu],
AC_FC_CHECK_BOUNDS for Fortran array bounds checking. (was: flags for different fortran compilers)
[ moving from autoconf@ to -patches@ ]
Hello,
here's a first macro to improve Fortran support in Autoconf.
It uses Fortran 90 interface declarations, so a F77 version
would have to be different (and I'm not quite sure whether
this works as well in Fortran 77). I only have access to a
few of the listed compilers, the other flags are taken from
manuals only. I gather fixes will come from users over time.
OK to push? Eve-Marie, OK to add your name and email to THANKS?
Thanks,
Ralf
New macro AC_FC_CHECK_BOUNDS to enable Fortran array bounds checking.
* lib/autoconf/fortran.m4 (AC_FC_CHECK_BOUNDS): New macro.
* doc/autoconf.texi (Fortran Compiler): Document it.
* tests/fortran.at (AC_FC_CHECK_BOUNDS): New test.
* NEWS, THANKS: Update.
Prompted by report from Eve-Marie Devaliere.
diff --git a/NEWS b/NEWS
index 3368d87..534bb17 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,9 @@ GNU Autoconf NEWS - User visible changes.
subdirectories if they have not been configured yet, so that an initial
makefile can be generated for a new sub package.
+** New macro AC_FC_CHECK_BOUNDS to enable array bounds checking in the Fortran
+ compiler.
+
** Macros
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1ccfcd3..a9bd40e 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8246,6 +8246,16 @@ Fortran Compiler
message).
@end defmac
+@defmac AC_FC_CHECK_BOUNDS (@ovar{action-if-success}, @ovar{action-if-failure})
+@acindex{FC_CHECK_BOUNDS}
+
+The @code{AC_FC_CHECK_BOUNDS} macro tries to enable array bounds checking
+in the Fortran compiler. If successful, the @var{action-if-success}
+is called and any needed flags are added to @code{FCFLAGS}. Otherwise,
+@var{action-if-failure} is called, which defaults to failing with an error
+message.
+@end defmac
+
@node Go Compiler
@subsection Go Compiler Characteristics
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index d5afbb9..de56323 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1357,3 +1357,75 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_LINE_LENGTH
+
+
+# AC_FC_CHECK_BOUNDS([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+# --
+# Look for a compiler flag to turn on array bounds checking for the
+# Fortran (FC) compiler, and adds it to FCFLAGS. Call
+# ACTION-IF-SUCCESS (defaults to nothing) if successful (i.e. can
+# compile code using new extension) and ACTION-IF-FAILURE (defaults to
+# failing with an error message) if not. (Defined via DEFUN_ONCE to
+# prevent flag from being added to FCFLAGS multiple times.)
+#
+# The known flags are:
+# -fbounds-check: GNU g77, gfortran
+# -CB, -check bounds: Intel compiler (icc, ecc, ifort)
+# -C: Sun/Oracle compiler (f95)
+#-C, -qcheck: IBM compiler (xlf)
+# -Mbounds: Portland Group compiler
+# -C, -check_bounds: SGI compiler
+# -check_bounds, +check=all: HP Fortran
+#-C, -Rb -Rc: Absoft (-Rb: array boundaries, -Rc: array conformance)
+#--check: Lahey
+AC_DEFUN_ONCE([AC_FC_CHECK_BOUNDS],
+[AC_LANG_PUSH([Fortran])dnl
+AC_CACHE_CHECK([for Fortran flag to enable array-bounds checking],
+ [ac_cv_fc_check_bounds],
+[ac_cv_fc_check_bounds=unknown
+ac_fc_check_bounds_FCFLAGS_save=$FCFLAGS
+for ac_flag in -fbounds-check -check_bounds -Mbounds -qcheck \
+ '-check bounds' +check=all --check '-Rb -Rc' -CB -C
+do
+ FCFLAGS=$ac_fc_check_bounds_FCFLAGS_save $ac_flag
+ # We should be able to link a correct program.
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
+[AC_LINK_IFELSE([[
+ subroutine sub(a)
+ integer a(:)
+ a(8) = 0
+ end subroutine
+
+ program main
+ integer a(1:7)
+ interface
+ subroutine sub(a)
+ integer a(:)
+ end subroutine
+ end interface
+
+ call sub(a)
+ end program]],
+ [# If we can run the program, require failure at run time.
+ # In cross-compiling mode, we rely on the compiler not accepting
+ # unknown options.
+ AS_IF([test $cross_compiling = yes],
+ [ac_cv_fc_check_bounds=$ac_flag; break],
+ [AS_IF([_AC_DO_TOKENS(./conftest$ac_exeext)],
+[],
+[ac_cv_fc_check_bounds=$ac_flag; break])])])])
+done
+rm -f conftest$ac_exeext conftest.err conftest.$ac_objext conftest.$ac_ext
+FCFLAGS=$ac_fc_check_bounds_FCFLAGS_save
+])
+if test x$ac_cv_fc_check_bounds = xunknown; then
+ m4_default([$2],
+ [AC_MSG_ERROR([no Fortran flag for bounds checking found], 77)])
+else
+ if test x$ac_cv_fc_check_bounds != xnone; then
+FCFLAGS=$FCFLAGS $ac_cv_fc_check_bounds
+ fi
+ $1
+fi
+AC_LANG_POP([Fortran])dnl
+])# AC_FC_CHECK_BOUNDS
diff --git a/tests/fortran.at b/tests/fortran.at
index f0fec7c..c4dd68e 100644
--- a/tests/fortran.at
+++ b/tests/fortran.at
@@ -930,3 +930,62 @@ EOF
done
AT_CLEANUP
+
+
+## --- ##
New macro AC_FC_IMPLICIT_NONE to disable Fortran implicit int.
Another fairly simple Fortran macro, with data gathered from manuals
and from the overview site which Eve-Marie linked to.
No test so far except for the automatic self-test created by mktests.sh.
OK to push?
Thanks,
Ralf
New macro AC_FC_IMPLICIT_NONE to disable Fortran implicit int.
* lib/autoconf/fortran.m4 (AC_FC_IMPLICIT_NONE): New macro.
* doc/autoconf.texi (Fortran Compiler): Document it.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index 534bb17..2c6478e 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,9 @@ GNU Autoconf NEWS - User visible changes.
** New macro AC_FC_CHECK_BOUNDS to enable array bounds checking in the Fortran
compiler.
+** New macro AC_FC_IMPLICIT_NONE to disable implicit int declarations in
+ Fortran.
+
** Macros
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index a9bd40e..64c3201 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8282,6 +8282,14 @@ Go Compiler
@code{GOFLAGS} may be set before @code{AC_PROG_GO}.
@end defmac
+@defmac AC_FC_IMPLICIT_NONE (@ovar{action-if-success},
@ovar{action-if-failure})
+@acindex{FC_IMPLICIT_NONE}
+
+Try to disallow implicit declarations in the Fortran compiler. If
+successful, the @var{action-if-success} is called and any needed flags
+are added to @code{FCFLAGS}. Otherwise, @var{action-if-failure} is
+called, which defaults to failing with an error message.
+@end defmac
@node System Services
@section System Services
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index de56323..416cf56 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1429,3 +1429,50 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_CHECK_BOUNDS
+
+
+# AC_FC_IMPLICIT_NONE([ACTION-IF-SUCCESS], [ACTION-IF-FAILURE = FAILURE])
+# ---
+# Look for a flag to disallow implicit declarations, and add it to FCFLAGS.
+# Call ACTION-IF-SUCCESS (defaults to nothing) if successful and
+# ACTION-IF-FAILURE (defaults to failing with an error message) if not.
+#
+# Known flags:
+# GNU gfortran: -fimplicit-none, g77: -Wimplicit
+# Intel: -u, -implicitnone
+# Sun/Oracle: -u
+# HP: +implicit_none
+# IBM: -u, -qundef
+# SGI: -u
+# Compaq: -u, -warn declarations
+# NAGware: -u
+# Lahey: --in
+AC_DEFUN([AC_FC_IMPLICIT_NONE],
+[AC_LANG_PUSH([Fortran])dnl
+AC_CACHE_CHECK([for flag to disallow Fortran implicit declarations],
+ [ac_cv_fc_implicit_none],
+[ac_cv_fc_implicit_none=unknown
+ac_fc_implicit_none_FCFLAGS_save=$FCFLAGS
+for ac_flag in none -fimplicit-none -u -Wimplicit -implicitnone +implicit_none
\
+ -qundef -warn declarations --in
+do
+ test x$ac_flag != xnone FCFLAGS=$ac_fc_implicit_none_FCFLAGS_save
$ac_flag
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [[
+ i = 0]])],
+[],
+[ac_cv_fc_implicit_none=$ac_flag; break])
+done
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+FCFLAGS=$ac_fc_implicit_none_FCFLAGS_save
+])
+if test x$ac_cv_fc_implicit_none = xunknown; then
+ m4_default([$3],
+[AC_MSG_ERROR([no Fortran flag to disallow implicit declarations found],
77)])
+else
+ if test x$ac_cv_fc_implicit_none != xnone; then
+FCFLAGS=$FCFLAGS $ac_cv_fc_implicit_none
+ fi
+ $2
+fi
+AC_LANG_POP([Fortran])dnl
+])# AC_FC_IMPLICIT_NONE
Reword Fortran macro documentation.
The formulation was a bit awkward to read, this should help it. OK?
Thanks,
Ralf
Reword Fortran macro documentation.
* doc/autoconf.texi (Fortran Compiler): Improve wording for
AC_FC_FREEFORM, AC_FC_FIXEDFORM, and AC_FC_LINE_LENGTH macros.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 64c3201..3db5db6 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8187,10 +8187,9 @@ Fortran Compiler
@defmac AC_FC_FREEFORM (@ovar{action-if-success}, @ovar{action-if-failure})
@acindex{FC_FREEFORM}
-The @code{AC_FC_FREEFORM} tries to ensure that the Fortran compiler
-(@code{$FC}) allows free-format source code (as opposed to the older
-fixed-format style from Fortran 77). If necessary, it may add some
-additional flags to @code{FCFLAGS}.
+Try to ensure that the Fortran compiler (@code{$FC}) allows free-format
+source code (as opposed to the older fixed-format style from Fortran
+77). If necessary, it may add some additional flags to @code{FCFLAGS}.
This macro is most important if you are using the default @file{.f}
extension, since many compilers interpret this extension as indicating
@@ -8210,10 +8209,9 @@ Fortran Compiler
@defmac AC_FC_FIXEDFORM (@ovar{action-if-success}, @ovar{action-if-failure})
@acindex{FC_FIXEDFORM}
-The @code{AC_FC_FIXEDFORM} tries to ensure that the Fortran compiler
-(@code{$FC}) allows the old fixed-format source code (as opposed to
-free-format style). If necessary, it may add some additional flags to
-@code{FCFLAGS}.
+Try to ensure that the Fortran compiler (@code{$FC}) allows the old
+fixed-format source code (as opposed to free-format style). If
+necessary, it may add some additional flags to @code{FCFLAGS}.
This macro is needed for some compilers alias names like @command{xlf95}
which assume free-form source code by default, and in case you want to
@@ -8233,12 +8231,12 @@ Fortran Compiler
@ovar{action-if-failure})
@acindex{FC_LINE_LENGTH}
-The @code{AC_FC_LINE_LENGTH} macro tries to ensure that the Fortran compiler
-(@code{$FC}) accepts long source code lines. The @var{length} argument
-may be given as 80, 132, or unlimited, and defaults to 132. Note that
-line lengths above 254 columns are not portable, and some compilers
-do not accept more than 132 columns at least for fixed format source.
-If necessary, it may add some additional flags to @code{FCFLAGS}.
+Try to ensure that the Fortran compiler (@code{$FC}) accepts long source
+code lines. The @var{length} argument may be given as 80, 132, or
+unlimited, and defaults to 132. Note that line lengths above 254
+columns are not portable, and some compilers do not accept more than 132
+columns at least for fixed format source. If necessary, it may add some
+additional flags to @code{FCFLAGS}.
If @code{AC_FC_LINE_LENGTH} succeeds in compiling fixed-form source, it
calls @var{action-if-success} (defaults to nothing). If it fails, it
Update documentation for AC_FC_LINE_LENGTH compiler switches.
I'll push this along the other commits once approved. (Rebasing and reordering the patches is a bit awkward, as the patches introducing new macros all append to the same file.) Thanks, Ralf Update documentation for AC_FC_LINE_LENGTH compiler switches. * lib/autoconf/fortran.m4 (AC_FC_LINE_LENGTH): Document NAGware switch. diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index 416cf56..338c51d 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/fortran.m4 @@ -1308,6 +1308,7 @@ AC_LANG_POP([Fortran])dnl # 132 free) # -wide: Lahey/Fujitsu Fortran (255 cols in fixed form) # -e: Sun Fortran compiler (132 characters) +#-132: NAGWare AC_DEFUN_ONCE([AC_FC_LINE_LENGTH], [AC_LANG_PUSH([Fortran])dnl m4_case(m4_default([$1], [132]),
New macro AC_FC_FPE_TRAP for Fortran FP Exception handling.
This patch is still in somewhat of an alpha stage. The new macro is
probably overly complex (and I'm not sure whether it's best to handle
the first argument at configure time, or earlier at autoconf time in
m4), and the test is too strict so that it fails on most systems.
The latter has two reasons (I think): my understanding of what causes
an FP exception is flawed, and both hardware and compilers and system
environments are not up to the task of supporting all the exceptions
(yet). Help is appreciated.
And I'm sure I'm mixing elements from various Fortran standards again
...
Thanks,
Ralf
New macro AC_FC_FPE_TRAP for Fortran FP Exception handling.
* lib/autoconf/fortran.m4 (AC_FC_FPE_TRAP): New macro.
* tests/fortran.at (AC_FC_FPE_TRAP): New test.
Prompted by report from Eve-Marie Devaliere.
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 338c51d..32efdf6 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1477,3 +1477,140 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_IMPLICIT_NONE
+
+
+# AC_FC_FPE_TRAP([EXCEPTION-LIST], [ACTION-IF-SUCCESS],
+#[ACTION-IF-FAILURE = FAILURE])
+# -
+# Look for a compiler flag to turn on FPE exceptions for the IEEE exceptions
+# listed in EXCEPTION-LIST. Run ACTION-IF-SUCCESS (defaults to nothing) if
+# successful, and ACTION-IF-FAILURE (defaults to failing with an error message)
+# if not. EXCEPTION-LIST is a comma-separated list of exceptions from the
+# following list: none, all, common, overflow, zero, invalid, underflow,
+# precision, denormal. 'common' denotes the common setting of enabling
+# overflow, divide by zero, and invalid.
+# Prepend `no-' to the exception in order to turn off the respective exception.
+#
+# Known flags:
+# GCC: -ffpe-trap=overflow,zero,invalid,underflow,precision,denormal
+# Intel: -fpe 0 -fpe 1 -fpe 3
+# Portland: -Ktrap=ovf,divz[,inv,unf,inexact,denorm,fp] (fp == inv,divz,ovf)
+# HP: +FP[V][Z][O][U][I][D]
+# (upper-case enables, lower-case disables
+#invalid fp ops, divide by zero, overflow, underflow, inexact)
+# Lahey: -[n]trap [d][i][o][u] (divide-by-zero, invalid op. overflow,
underflow)
+# IBM: -qflttrap=zerodivide:enable -qsigtrap
+# -qnoflttrap
+# (zerodivide, underflow, overflow, invalid, inexact, enable,
+# imprecise, nanq)
+# -qflttrap without suboptions is equivalent to
+# -qflttrap=inv:inex:ov:und:zero
+# -qsigtrap
+# Sun/Oracle: -ftrap=%all,no%inexact -ftrap=common
+# %all, %none, common, [no%]invalid, [no%]overflow,
[no%]underflow,
+# %[no%]division, [no%]inexact.
+# -ftrap=common is a macro for -ftrap=invalid,overflow,division.
+# Absoft: -TENV:simd_[idzoup]mask{=off}
+# -trap={INVALID,DIVBYZERO,OVERFLOW,UNDERFLOW,INEXACT,ALL}[,...]
+# SGI: -trapuv
+# MIPS: TRAP_FPE environment variable
+# NAGware: -ieee={full,nonstd,stop}, -nan
+# Compaq: -fpe -fpex
+AC_DEFUN([AC_FC_FPE_TRAP],
+[AC_LANG_PUSH([Fortran])dnl
+m4_pushdef([fpe_traps], [m4_default([$1], [common])])dnl
+AC_CACHE_CHECK([for Fortran flag to set FPE traps fpe_traps],
+ [ac_cv_fc_fpe_trap],
+[ac_cv_fc_fpe_trap=unknown
+ac_fc_fpe_trap_FCFLAGS_save=$FCFLAGS
+# Table consisting of:
+# - option name,
+# - option-argument separator,
+# - argument separator,
+# - option for no traps,
+# - option for all traps,
+# - option for common traps,
+# - trap names for overflow, division by zero, invalid, underflow, precision,
+# denormal, interleaved with negated values.
+# The table is eval'ed to allow to enter white space and empty arguments.
+m4_define([_AC_FC_FPE_FLAGS],
+ [overflow zero invalid underflow precision denormal])dnl
+ac_fc_fpe_flags='_AC_FC_FPE_FLAGS'
+for ac_fc_flag_table in \
+'-ffpe-trap= ,
-ffpe-trap=overflow,zero,invalid,underflow,precision,denormal \
+ -ffpe-trap=overflow,zero,invalid \
+ overflow zero invalid underflow precision denormal ' \
+' -fpe 1 -fpe 3 -fpe 0' \
+'-Ktrap= , -Ktrap=ovf,divz,inv,unf,inexact,denorm -Ktrap=ovf,divz,inv \
+ ovf divz inv unf inexact denorm ' \
+'+FP +FP ozvuid +FP OZVUID +FP VZO O Z V U I D o z v u i d' \
+'-ftrap= , -ftrap=%none -ftrap=%all -ftrap=common \
+ overflow division invalid underflow inexact \
+ no%overflow no%division no%invalid no%underflow no%inexact ' \
+'-qflttrap=en: : -qnoflttrap -qflttrap=ov:zero:inv:und:inex:en
-qflttrap=inv:ov:zero:en \
+ ov zero inv und inex ' \
+'-trap -trap diou -ntrap -trap dio o d i u' \
+'-trap= , -trap=ALL \
+ OVERFLOW DIVBYZERO INVALID UNDERFLOW INEXACT ' \
+'-TENV: : -TENV:X=3 -TENV:simd_omask=ON:simd_imask=ON:simd_zmask=ON \
+ simd_omask=ON simd_zmask=ON simd_imask=ON simd_umask=ON simd_pmask=ON
simd_dmask=ON \
+ simd_omask=OFF simd_zmask=OFF simd_imask=OFF simd_umask=OFF simd_pmask=OFF
simd_dmask=OFF' \
+' -ieee=full -ieee=nonstd'
+do
+ eval set
Re: Update documentation for AC_FC_LINE_LENGTH compiler switches.
* Ralf Wildenhues wrote on Sun, Feb 27, 2011 at 05:27:42PM CET: I'll push this along the other commits once approved. (Rebasing and reordering the patches is a bit awkward, as the patches introducing new macros all append to the same file.) Never mind, I meant to merge another bit in this patch: Update AC_FC_LINE_LENGTH compiler switches. * lib/autoconf/fortran.m4 (AC_FC_LINE_LENGTH): Document NAGware switch. Update Absoft switches. diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index 416cf56..104ebe7 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/fortran.m4 @@ -1303,11 +1303,12 @@ AC_LANG_POP([Fortran])dnl # accepts that as well with an optional parameter and # doesn't fail but only warns about unknown arguments. # -extend_source: SGI compiler -# -W NN (132, 80, 72): Absoft Fortran +# -W, -WNN (132, 80, 72): Absoft Fortran # +extend_source: HP Fortran (254 in either form, default is 72 fixed, # 132 free) # -wide: Lahey/Fujitsu Fortran (255 cols in fixed form) # -e: Sun Fortran compiler (132 characters) +#-132: NAGWare AC_DEFUN_ONCE([AC_FC_LINE_LENGTH], [AC_LANG_PUSH([Fortran])dnl m4_case(m4_default([$1], [132]), @@ -1336,7 +1337,7 @@ for ac_flag in none \ -ffixed-line-length-$ac_fc_line_len \ -qfixed=$ac_fc_line_len -Mextend \ -$ac_fc_line_len -extend_source \ - -W $ac_fc_line_len +extend_source -wide -e + -W$ac_fc_line_len -W +extend_source -wide -e do test x$ac_flag != xnone FCFLAGS=$ac_fc_line_length_FCFLAGS_save $ac_flag AC_COMPILE_IFELSE([[$ac_fc_line_length_test
Re: New macro AC_FC_FPE_TRAP for Fortran FP Exception handling.
* Ralf Wildenhues wrote on Sun, Feb 27, 2011 at 05:37:27PM CET:
This patch is still in somewhat of an alpha stage. The new macro is
probably overly complex (and I'm not sure whether it's best to handle
the first argument at configure time, or earlier at autoconf time in
m4), and the test is too strict so that it fails on most systems.
Updated patch with weaker test, passes for me with gfortran 4.3.5,
Intel, XL, Sun on GNU/Linux, and only fails the autogenerated test with
Sun on Solaris because a core file is generated.
Sorry for the noise.
Cheers,
Ralf
New macro AC_FC_FPE_TRAP for Fortran FP Exception handling.
* lib/autoconf/fortran.m4 (AC_FC_FPE_TRAP): New macro.
* tests/fortran.at (AC_FC_FPE_TRAP): New test.
Prompted by report from Eve-Marie Devaliere.
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 104ebe7..0f2564b 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -1477,3 +1477,175 @@ else
fi
AC_LANG_POP([Fortran])dnl
])# AC_FC_IMPLICIT_NONE
+
+
+# AC_FC_FPE_TRAP([EXCEPTION-LIST], [ACTION-IF-SUCCESS],
+#[ACTION-IF-FAILURE = FAILURE])
+# -
+# Look for a compiler flag to turn on FPE exceptions for the IEEE exceptions
+# listed in EXCEPTION-LIST. Run ACTION-IF-SUCCESS (defaults to nothing) if
+# successful, and ACTION-IF-FAILURE (defaults to failing with an error message)
+# if not. EXCEPTION-LIST is a comma-separated list of exceptions from the
+# following list: none, all, common, overflow, zero, invalid, underflow,
+# precision, denormal. 'common' denotes the common setting of enabling
+# overflow, divide by zero, and invalid.
+# Prepend `no-' to the exception in order to turn off the respective exception.
+#
+# Known flags:
+# GCC: -ffpe-trap=overflow,zero,invalid,underflow,precision,denormal
+# Intel: -fpe0 -fpe1 -fpe3
+# Portland: -Ktrap=ovf,divz[,inv,unf,inexact,denorm,fp] (fp == inv,divz,ovf)
+# HP: +FP[V][Z][O][U][I][D]
+# (upper-case enables, lower-case disables
+#invalid fp ops, divide by zero, overflow, underflow, inexact)
+# Lahey: -[n]trap [d][i][o][u] (divide-by-zero, invalid op. overflow,
underflow)
+# IBM: -qflttrap=zerodivide:enable -qsigtrap
+# -qnoflttrap
+# (zerodivide, underflow, overflow, invalid, inexact, enable,
+# imprecise, nanq)
+# -qflttrap without suboptions is equivalent to
+# -qflttrap=inv:inex:ov:und:zero
+# -qsigtrap
+# Sun/Oracle: -ftrap=%all,no%inexact -ftrap=common
+# %all, %none, common, [no%]invalid, [no%]overflow,
[no%]underflow,
+# %[no%]division, [no%]inexact.
+# -ftrap=common is a macro for -ftrap=invalid,overflow,division.
+# Absoft: -TENV:simd_[idzoup]mask{=off}
+# -trap={INVALID,DIVBYZERO,OVERFLOW,UNDERFLOW,INEXACT,ALL}[,...]
+# SGI: -trapuv
+# MIPS: TRAP_FPE environment variable
+# NAGware: -ieee={full,nonstd,stop}, -nan
+# Compaq: -fpe -fpex
+AC_DEFUN([AC_FC_FPE_TRAP],
+[AC_LANG_PUSH([Fortran])dnl
+m4_pushdef([fpe_traps], [m4_default([$1], [common])])dnl
+AC_CACHE_CHECK([for Fortran flag to set FPE traps fpe_traps],
+ [ac_cv_fc_fpe_trap],
+[ac_cv_fc_fpe_trap=unknown
+ac_fc_fpe_trap_FCFLAGS_save=$FCFLAGS
+# Table consisting of:
+# - option name,
+# - option-argument separator,
+# - argument separator,
+# - option for no traps,
+# - option for all traps,
+# - option for common traps,
+# - trap names for overflow, division by zero, invalid, underflow, precision,
+# denormal, interleaved with negated values.
+# The table is eval'ed to allow to enter white space and empty arguments.
+# The Intel entry comes first since the compiler ignores unknown arguments.
+m4_define([_AC_FC_FPE_FLAGS],
+ [overflow zero invalid underflow precision denormal])dnl
+ac_fc_fpe_flags='_AC_FC_FPE_FLAGS'
+for ac_fc_flag_table in \
+' -fpe1 -fpe3 -fpe0' \
+'-ffpe-trap= ,
-ffpe-trap=overflow,zero,invalid,underflow,precision,denormal \
+ -ffpe-trap=overflow,zero,invalid \
+ overflow zero invalid underflow precision denormal ' \
+'-Ktrap= , -Ktrap=ovf,divz,inv,unf,inexact,denorm -Ktrap=ovf,divz,inv \
+ ovf divz inv unf inexact denorm ' \
+'+FP +FP ozvuid +FP OZVUID +FP VZO O Z V U I D o z v u i d' \
+'-ftrap= , -ftrap=%none -ftrap=%all -ftrap=common \
+ overflow division invalid underflow inexact \
+ no%overflow no%division no%invalid no%underflow no%inexact ' \
+'-qflttrap=en: : -qnoflttrap -qflttrap=ov:zero:inv:und:inex:en
-qflttrap=inv:ov:zero:en \
+ ov zero inv und inex ' \
+'-trap -trap diou -ntrap -trap dio o d i u' \
+'-trap= , -trap=ALL \
+ OVERFLOW DIVBYZERO INVALID UNDERFLOW INEXACT ' \
+'-TENV: : -TENV:X=3 -TENV:simd_omask=ON:simd_imask=ON:simd_zmask=ON \
+ simd_omask=ON simd_zmask=ON simd_imask=ON simd_umask=ON simd_pmask=ON
simd_dmask=ON \
+ simd_omask=OFF simd_zmask=OFF simd_imask=OFF simd_umask=OFF simd_pmask=OFF
simd_dmask=OFF' \
+' -ieee=full -ieee
Re: bug#8111: after adding a(nother) subconfigure, rerunning make fails
[ dropping bug-automake ]
* Jack Kelly wrote on Fri, Feb 25, 2011 at 10:38:39PM CET:
On Sat, Feb 26, 2011 at 7:46 AM, Ralf Wildenhues wrote:
[ adding autoconf-patches; this is http://debbugs.gnu.org/8111 ]
* Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET:
On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote:
 Since 'makefile' might be spelt in various different
ways, we can take presence of 'config.status' in the subdir build tree
as indicator, that should be good enough.
You should add a comment to this effect in your status.m4 changes.
Currently, it looks like you've tested for config.status by mistake.
Indeed, thanks.
I'm still wondering whether we should rename the option
--new-recursion-only however, that would be more precise.
Other than that, the patch below seems to do what I want.
Yes. the name becomes very confusing. Maybe --recursion=no (with
--no-recursion as an alias), --recursion=new-only?
That's better.
Eric, what do you think about this patch? The test suite is still
running, but it's past the torture.at stage so I don't expect further
surprises.
I chose to not rename the internal $no_recursion for now. It looks a
big ugly the way it is, but codesearch tells me that user configure.ac
scripts are using this variable actively, e.g. the GCC/src/binutils/gdb
trees, or in erlang-otp. The latter would need fixing anyway I guess;
see git://github.com/mfoemmel/erlang-otp.git. So somebody will lose
here.
Should I compactify the install.texi diff? Markup-wise, would that be
+@itemx --recursion=@r{@{}no@r{|}yes@r{|}new-only@r{@}}
?
automake/lib/config-ml.in will need a (trivial) update for this too.
Thanks,
Ralf
configure reruns now enter new subpackages.
Assume you have a project that provides rebuild rules (e.g.,
those from automake), and an up to date build tree. If you add
a new subpackage, `make' will trigger `config.status --recheck'
but the new subpackage will never be configured, as it has no
makefile yet. This patch changes config.status to pass the new
option --recursion=new-only rather than --no-recursion to
configure, so that new subdirectories will be configured.
* doc/autoconf.texi (Setting Output Variables): Update example
output.
(config.status Invocation): Document that config.status uses
--recursion=new-only now.
* doc/install.texi (configure Invocation): Document
--no-recursion, --recursion={no,yes,new-only}.
* lib/autoconf/general.m4 (_AC_INIT_PARSE_ARGS, _AC_INIT_HELP):
Accept and document the new options.
(_AC_INIT_PREPARE): Strip the options out so they don't pile up.
* lib/autoconf/status.m4 (_AC_OUTPUT_SUBDIRS): If new-only, do
not configure a subdir that already has a config.status file.
(_AC_OUTPUT_CONFIG_STATUS): Pass --recursion=new-only instead of
--no-recursion.
* tests/torture.at (New AC_CONFIG_SUBDIRS): New test.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index 3edebd8..3368d87 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,13 @@ GNU Autoconf NEWS - User visible changes.
** AS_LITERAL_IF again treats '=' as a literal. Regression introduced in
2.66.
+** configure now also accepts arguments --recursion={no,yes,new-only}, with
+ the first being an alias for --no-recursion and the second the default.
+ `config.status --recheck' now triggers the `new-only' case which enters
+ subdirectories if they have not been configured yet, so that an initial
+ makefile can be generated for a new sub package.
+
+
** Macros
- New macro AC_HEADER_CHECK_STDBOOL.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index b011316..1ccfcd3 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -9712,7 +9712,7 @@ Setting Output Variables
$ @kbd{CC=/usr/bin/cc ./configure var=raboof --silent}
$ @kbd{./config.status --recheck}
running CONFIG_SHELL=/bin/sh /bin/sh ./configure var=raboof \
- CC=/usr/bin/cc --no-create --no-recursion
+ CC=/usr/bin/cc --no-create --recursion=new-only
@end example
@end itemize
@end defmac
@@ -22088,10 +22088,11 @@ config.status Invocation
@option{--recheck} option reruns @command{configure} with the same arguments
you used before, plus the @option{--no-create} option, which prevents
@command{configure} from running @file{config.status} and creating
-@file{Makefile} and other files, and the @option{--no-recursion} option,
+@file{Makefile} and other files, and the @option{--recursion=new-only} option,
which prevents @command{configure} from running other @command{configure}
-scripts in subdirectories. (This is so other Make rules can
-run @file{config.status} when it changes; @pxref{Automatic Remaking},
+scripts in subdirectories that have already been configured before.
+(This is so other Make rules can run @file{config.status} when it changes;
+@pxref{Automatic Remaking},
for an example).
@end table
diff --git a/doc/install.texi b/doc/install.texi
index d397b8a..46482a3 100644
Do not quote $SHELL when rerunning configure
Hello Paul, all, in commit 1be64afa5b45bf6cd82a0d118d8442527d9296fe, you quoted '$SHELL' in the code below. That strikes me as weird, because it prevents me from doing funky debugging like this: CONFIG_SHELL='/bin/sh -x' /bin/sh -x ./configure ./config.status --recheck # I'd like it to use sh -x I /think/ all other instances of SHELL or CONFIG_SHELL already allow more than one word. I am not aware of any system for which one of the normally-used shells has an absolute file name containing a space. I don't really think we need to cater to w32 users actively trying to shoot themselves in the foot. This patch (trivially) conflicts with the --recursion=new-only patch. Thanks, Ralf config.status: do not quote $SHELL when rerunning configure. * lib/autoconf/status.m4 (_AC_OUTPUT_CONFIG_STATUS): Allow $SHELL to contain more than one word, when rerunning configure, for debugging purposes like CONFIG_SHELL='/bin/sh -x'. diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4 index 00cbb31..f50f503 100644 --- a/lib/autoconf/status.m4 +++ b/lib/autoconf/status.m4 @@ -1547,7 +1547,7 @@ cat $CONFIG_STATUS _ACEOF || ac_write_fail=1 dnl Check this before opening the log, to avoid a bug on MinGW, dnl which prohibits the recursive instance from truncating an open log. if \$ac_cs_recheck; then - set X '$SHELL' '$[0]' $ac_configure_args \$ac_configure_extra_args --no-create --recursion=new-only + set X $SHELL '$[0]' $ac_configure_args \$ac_configure_extra_args --no-create --recursion=new-only shift \AS_ECHO([running CONFIG_SHELL=$SHELL \$[*]]) AS_MESSAGE_FD CONFIG_SHELL='$SHELL'
Exclude M4 with buggy strstr when configuring Autoconf. (was: configure oddity)
[ dropping lots of cc, adding autoconf-patches ]
Hi Eric,
* Eric Blake wrote on Sat, Feb 26, 2011 at 03:02:25PM CET:
I like the concept, although I can make it shorter.
Autoconf's m4/m4.m4 needs a similar test.
Thanks. Like this?
I should note that it won't exclude a buggy m4 that the user has
explicitly set by setting the M4 environment variable.
It seems like a bug in AC_MSG_ERROR that I cannot use a comma in
the message, with the current amount of quoting.
Thanks,
Ralf
2011-02-26 Ralf Wildenhues ralf.wildenh...@gmx.de
Eric Blake ebl...@redhat.com
Exclude M4 with buggy strstr when configuring Autoconf.
* m4/m4.m4 (AC_PROG_GNU_M4): When searching PATH, do not accept
an m4 that has the gnulib strstr bug.
diff --git a/m4/m4.m4 b/m4/m4.m4
index a11fe0d..5aef986 100644
--- a/m4/m4.m4
+++ b/m4/m4.m4
@@ -1,4 +1,4 @@
-# m4.m4 serial 11
+# m4.m4 serial 12
# Copyright (C) 2000, 2006-2011 Free Software Foundation, Inc.
@@ -25,15 +25,18 @@ AS_UNSET([POSIXLY_CORRECT])
AC_PATH_PROGS_FEATURE_CHECK([M4], [m4 gm4 gnum4],
[dnl Creative quoting here to avoid raw dnl and ifdef in configure.
# Root out GNU M4 1.4.5, as well as non-GNU m4 that ignore -t, -F.
+ # Root out GNU M4 1.4.13 and 1.4.14 with buggy replacement strstr.
ac_snippet=change'quote(,)in''dir(if''def,mac,bug)'
ac_snippet=${ac_snippet}pat'subst(a,\(b\)\|\(a\),\1)d'nl
+
ac_snippet=${ac_snippet}${as_nl}if'else(in''dex(..wi.d.,.d.),-1,strstr-bug)'
test -z `$ac_path_M4 -F conftest.m4f /dev/null 21` \
test -z `AS_ECHO([$ac_snippet]) | $ac_path_M4 --trace=mac 21` \
test -f conftest.m4f \
ac_cv_path_M4=$ac_path_M4 ac_path_M4_found=:
rm -f conftest.m4f],
[AC_MSG_ERROR([no acceptable m4 could be found in \$PATH.
-GNU M4 1.4.6 or later is required; 1.4.14 is recommended])])])
+GNU M4 1.4.6 or later is required; 1.4.13 or 1.4.16+ are recommended.
+GNU M4 1.4.14 and 1.4.15 use a buggy strstr on some systems])])])
M4=$ac_cv_path_M4
AC_CACHE_CHECK([whether $ac_cv_path_M4 accepts --gnu],
[ac_cv_prog_gnu_m4_gnu],
Re: bug#8111: after adding a(nother) subconfigure, rerunning make fails
[ adding autoconf-patches; this is http://debbugs.gnu.org/8111 ] * Jack Kelly wrote on Thu, Feb 24, 2011 at 11:49:44PM CET: On Fri, Feb 25, 2011 at 6:36 AM, Ralf Wildenhues wrote: Can we fix this somehow in either Autoconf or Automake? Could we save the results of tracing AC_CONFIG_SUBDIRS calls? If there's a change, invoke ./config.status --recheck. If not, config.status --recheck --no-recursion. Well, the rule that invokes 'config.status --recheck', let's call it the config.status rule, does not invoke any autotools, thus no m4. Any rule that invokes m4 must be a developer rule, but the config.status rule is a user rule, which is even in place with maintainer-mode. So we cannot mix these two concepts. (Aside, config.status --recheck invokes configure with --no-create and --no-recursion added, among the other arguments. Sorry for the nitpicking.) But I think we can still have our cake and eat it too: if I remove the --no-recursion from the list of arguments passed to configure, then the test starts to pass (once the missing AC_OUTPUT in the lib/configure.ac is fixed). Of course, we don't want to do that outright: if there is already a makefile in the subdir, then we don't want to recurse: the subdir makefile might want to run other rebuilding rules first. But if there isn't, and there is a configure script we can run, then I think we should do that. Since 'makefile' might be spelt in various different ways, we can take presence of 'config.status' in the subdir build tree as indicator, that should be good enough. I'm still wondering whether we should rename the option --new-recursion-only however, that would be more precise. Other than that, the patch below seems to do what I want. Comments? (And of course the test will need to be rewritten for Autoconf's test suite and amended to ensure we don't recurse when we shouldn't, and documentation and all that ...) Thanks, Ralf diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 index 337aba7..ce80dde 100644 --- a/lib/autoconf/general.m4 +++ b/lib/autoconf/general.m4 @@ -751,7 +751,7 @@ do -no-recursion | --no-recursion | --no-recursio | --no-recursi \ | --no-recurs | --no-recur | --no-recu | --no-rec | --no-re | --no-r) -no_recursion=yes ;; +no_recursion=new-only ;; -oldincludedir | --oldincludedir | --oldincludedi | --oldincluded \ | --oldinclude | --oldinclud | --oldinclu | --oldincl | --oldinc \ diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4 index a1a857b..00d5721 100644 --- a/lib/autoconf/status.m4 +++ b/lib/autoconf/status.m4 @@ -1181,6 +1181,11 @@ if test $no_recursion != yes; then # parts of a large source tree are present. test -d $srcdir/$ac_dir || continue +# If recursing to new subpackages only, skip those that have makefiles. +if test $no_recursion = new-only test -x $ac_dir/config.status; then + continue +fi + ac_msg configuring in $ac_dir (`pwd`/$ac_dir) _AS_ECHO_LOG([$ac_msg]) _AS_ECHO([$ac_msg])
Re: PATCH RFA: Add support for Go programming language
Hi Eric, * Eric Blake wrote on Mon, Feb 21, 2011 at 03:06:17PM CET: On 02/20/2011 10:35 AM, Ralf Wildenhues wrote: Thanks. Eric, would you mind if I went ahead with this patch? Sorry for my long silence on the matter. No worries. I'm fully aware that I have high review latency too, and am responsible for some long-standing testsuite regressions in Autoconf[1], but this patch feels like a no-brainer to me, and it would be really nice to get it off the pending list after four months. Yes, let's get this committed. I'm still quite busy with other tasks this week, but hope to have more time to properly visit autoconf issues later this month. Great. I've pushed this patch now, I hope that was what you meant with your mail, rather than asking me to wait for your review. Thanks, Ralf
Re: PATCH RFA: Add support for Go programming language
Hello, * Paul Eggert wrote on Sun, Feb 13, 2011 at 09:35:31PM CET: On 02/13/2011 09:04 AM, Ralf Wildenhues wrote: Any reasons against pushing this once a test with gccgo installed passes as well? The patch looks good to me; as you say, it shouldn't break existing uses. I'd like to also hear Eric's opinion on this. Thanks. Eric, would you mind if I went ahead with this patch? I'm fully aware that I have high review latency too, and am responsible for some long-standing testsuite regressions in Autoconf[1], but this patch feels like a no-brainer to me, and it would be really nice to get it off the pending list after four months. Thanks, Ralf [1] If they bother too much, one trivial improvement would be to just remove the offending tests from the testsuite for now.
Re: AC_OPENMP broken for IBM xl Fortran compilers
[ dropping autoconf@, adding bug-gnulib@ ] * Christian Rössel wrote on Sun, Feb 20, 2011 at 11:06:40AM CET: Am 2/20/2011 7:55 AM, schrieb Ralf Wildenhues: * Christian Rössel wrote on Fri, Feb 18, 2011 at 03:57:30PM CET: AC_OPENMP returns none needed for the IBM xl Fortran compilers (xlf*, bgxlf*, mpixlf*). This is wrong, you need to use -qsmp=omp. configure tries to compile following program: [...] Compilation succeeds without specifying any OpenMP flag. If you modify the test program to [...] the correct flags are detected. Thanks for the bug report and patch. I have one question (and I'd still like to do some testing before pushing): Isn't the '!' line a Fortran 90 comment, and doesn't that have to be written differently for pure Fortran 77? you are right, a '!' is usually a comment in Fortran. But in the context of OpenMP and combined with the '$' it is interpreted as a conditional compilation sentinel, i.e. if no OpenMP flags are passed to the compiler, the line is interpreted as a comment, otherwise '!$' is replaced by two spaces and the line gets compiled. See 2.2.1 and 2.2.2 in the OpenMP specification (http://www.openmp.org/mp-documents/spec30.pdf). The patch should work for Fortran 77 and 90. Thanks for the explanation and the pointer. I confirmed that even the old OpenMP 1.0 specification requires this, so we're quite safe here. I've pushed your patch, after adding Markus to THANKS, with the ChangeLog entry as below, to git Autoconf. The '(tiny change)' annotations only denote that you haven't done copyright assignment yet. Bruno, OK to merge to gnulib as below, in Christian's name? Thanks, Ralf 2011-02-20 Christian Rössel ... (tiny change) Markus Geimer ... (tiny change) Fix OpenMP flag detection for various Fortran compilers. * lib/autoconf/c.m4 (_AC_LANG_OPENMP(Fortran 77)): Use '!$' OpenMP-conditional compilation construct, to force compile failure with missing OpenMP flag. (AC_OPENMP): Add flags for Cray CCE and NEC SX compilers. * THANKS: Update. 2011-02-20 Christian Rössel ... (tiny change) Markus Geimer ... (tiny change) Fix OpenMP flag detection for various Fortran compilers. * m4/openmp.m4 (_AC_LANG_OPENMP(Fortran 77)): Use '!$' OpenMP-conditional compilation construct, to force compile failure with missing OpenMP flag. (AC_OPENMP): Add flags for Cray CCE and NEC SX compilers. diff --git a/m4/openmp.m4 b/m4/openmp.m4 index f2424df..cedfb4c 100644 --- a/m4/openmp.m4 +++ b/m4/openmp.m4 @@ -1,4 +1,4 @@ -# openmp.m4 serial 7 +# openmp.m4 serial 8 dnl Copyright (C) 2006-2011 Free Software Foundation, Inc. dnl This file is free software; the Free Software Foundation dnl gives unlimited permission to copy and/or distribute it, @@ -35,7 +35,14 @@ m4_copy([_AC_LANG_OPENMP(C)], [_AC_LANG_OPENMP(C++)]) # _AC_LANG_OPENMP(Fortran 77) # --- m4_define([_AC_LANG_OPENMP(Fortran 77)], -[AC_LANG_FUNC_LINK_TRY([omp_get_num_threads])]) +[ + program main + implicit none +!$integer tid + tid = 42 + call omp_set_num_threads(2) + end +]) # _AC_LANG_OPENMP(Fortran) # --- @@ -70,12 +77,14 @@ AC_DEFUN([AC_OPENMP], dnl SGI C, PGI C -mp dnl Tru64 Compaq C -omp dnl IBM C (AIX, Linux) -qsmp=omp + dnl Cray CCE -homp + dnl NEC SX -Popenmp dnl If in this loop a compiler is passed an option that it doesn't dnl understand or that it misinterprets, the AC_LINK_IFELSE test dnl will fail (since we know that it failed without the option), dnl therefore the loop will continue searching for an option, and dnl no output file called 'penmp' or 'mp' is created. - for ac_option in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp; do + for ac_option in -fopenmp -xopenmp -openmp -mp -omp -qsmp=omp -homp -Popenmp; do ac_save_[]_AC_LANG_PREFIX[]FLAGS=$[]_AC_LANG_PREFIX[]FLAGS _AC_LANG_PREFIX[]FLAGS=$[]_AC_LANG_PREFIX[]FLAGS $ac_option AC_LINK_IFELSE([_AC_LANG_OPENMP],
Re: PATCH RFA: Add support for Go programming language
* Ralf Wildenhues wrote on Mon, Dec 20, 2010 at 08:15:29AM CET: * Eric Blake wrote on Wed, Nov 03, 2010 at 06:42:54PM CET: On 11/03/2010 11:38 AM, Ian Lance Taylor wrote: It otherwise seems low-danger to me, but I wouldn't want to move forward on the Libtool sister patch without this one cleared. I'm at the point with my gcc patches where I kind of need an answer to this question. The question is: what name should we use in shell and make to refer to the Go compiler? I've been using GCCGO. Should we instead use GOC or GOCC or something else? How can we decide this? Personally, I'd like GOC mnemonic of Go-compiler (to match FC for Fortran-compiler, or CC for C compiler). GOC is used now in the Libtool patch for Go support (which has a replacement macro for AC_PROG_GO if that is not defined). This patch has been on hold for a while now, but I don't see a good reason for that. Eric, if you're still thinking of a stable release, but don't have time, then please outline your plans for that; maybe someone else has time to do that grunt work then. In any case it shouldn't need to hold up this patch, as it has only a small chance of actually introducing regressions for working code. So, here's a rebase, including s/GCCGO/GOC/g as discussed before, adjusting copyright years, and adding a NEWS entry. I've tested it without gccgo in sight, and a distcheck, and added a missing $(srcdir)/acgo.at entry in tests/Makefile.am. Any reasons against pushing this once a test with gccgo installed passes as well? Thanks, Ralf From 692e25444aa4b58e31711753de2326cfe1dc3a7c Mon Sep 17 00:00:00 2001 From: Ian Lance Taylor i...@google.com Date: Tue, 12 Oct 2010 12:26:39 -0700 Subject: [PATCH] Add support for the Go programming language. * lib/autoconf/go.m4: New file. * lib/autoconf/autoconf.m4: Include autoconf/go.m4. * lib/autoconf/Makefile.am (dist_autoconflib_DATA): Add go.m4. * lib/freeze.mk (autoconf_m4f_dependencies): Add $(src_libdir)/autoconf/go.m4. * doc/autoconf.texi: Rebuild menus. (Preset Output Variables): Mention Go. Document GOFLAGS. (Libraries): Mention Go. (Go Compiler): New subsection. (Language Choice): Mention Go. (Generating Sources): Likewise. (Running the Preprocessor): Likewise. * tests/go.at: New file. * tests/suite.at: Include go.at and acgo.at. * tests/local.at (_AT_CHECK_ENV): Add GOC and GOFLAGS. * tests/Makefile.am (TESTSUITE_GENERATED_AT): Add $(srcdir)/acgo.at. (TESTSUITE_HAND_AT): Add go.at. (AUTOCONF_FILES): Add $(autoconfdir)/go.m4. * NEWS: Update. --- ChangeLog| 23 ++ NEWS |3 + doc/autoconf.texi| 57 +--- lib/autoconf/Makefile.am |2 +- lib/autoconf/autoconf.m4 |1 + lib/autoconf/go.m4 | 177 ++ lib/freeze.mk|1 + tests/Makefile.am|4 +- tests/go.at | 35 + tests/local.at |1 + tests/suite.at |2 + 11 files changed, 295 insertions(+), 11 deletions(-) create mode 100644 lib/autoconf/go.m4 create mode 100644 tests/go.at diff --git a/ChangeLog b/ChangeLog index 6f0b93d..cf124e2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,26 @@ +2011-02-13 Ian Lance Taylor i...@google.com + + * lib/autoconf/go.m4: New file. + * lib/autoconf/autoconf.m4: Include autoconf/go.m4. + * lib/autoconf/Makefile.am (dist_autoconflib_DATA): Add go.m4. + * lib/freeze.mk (autoconf_m4f_dependencies): Add + $(src_libdir)/autoconf/go.m4. + * doc/autoconf.texi: Rebuild menus. + (Preset Output Variables): Mention Go. Document GOFLAGS. + (Libraries): Mention Go. + (Go Compiler): New subsection. + (Language Choice): Mention Go. + (Generating Sources): Likewise. + (Running the Preprocessor): Likewise. + * tests/go.at: New file. + * tests/suite.at: Include go.at and acgo.at. + * tests/local.at (_AT_CHECK_ENV): Add GOC and GOFLAGS. + * tests/Makefile.am (TESTSUITE_GENERATED_AT): Add + $(srcdir)/acgo.at. + (TESTSUITE_HAND_AT): Add go.at. + (AUTOCONF_FILES): Add $(autoconfdir)/go.m4. + * NEWS: Update. + 2011-02-12 Giulio Paci giuliop...@interfree.it (tiny change) Ralf Wildenhues ralf.wildenh...@gmx.de diff --git a/NEWS b/NEWS index c485f22..3edebd8 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,9 @@ GNU Autoconf NEWS - User visible changes. * Noteworthy changes in release ?.? (-??-??) [?] +** Support for the Go programming language has been added. The new macro + AC_LANG_GO sets variables GOC and GOFLAGS. + ** AS_LITERAL_IF again treats '=' as a literal. Regression introduced in 2.66. diff --git a/doc/autoconf.texi b/doc/autoconf.texi index badf11d..508352a 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -413,6 +413,7 @@ Compilers and Preprocessors * Objective C++ Compiler:: Likewise * Erlang Compiler
rebuild texinfo menus
OK?
Thanks,
Ralf
2011-02-06 Ralf Wildenhues ralf.wildenh...@gmx.de
* doc/autoconf.texi: Rebuild menus using emacs ^C ^U ^A.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1fbb7ad..232ed81 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -340,7 +340,7 @@ Top
* Preset Output Variables:: Output variables that are always set
* Installation Directory Variables:: Other preset output variables
-* Changed Directory Variables:: Warnings about @file{datarootdir}
+* Changed Directory Variables:: Warnings about @file{datarootdir}
* Build Directories:: Supporting multiple concurrent compiles
* Automatic Remaking:: Makefile rules for configuring
@@ -452,13 +452,6 @@ Top
* Programming in M4sugar:: Convenient pure M4 macros
* Debugging via autom4te:: Figuring out what M4 was doing
-Programming in M4sh
-
-* Common Shell Constructs:: Portability layer for common shell constructs
-* Polymorphic Variables:: Support for indirect variable names
-* Initialization Macros:: Macros to establish a sane shell environment
-* File Descriptor Macros:: File descriptor macros for input and output
-
M4 Quotation
* Active Characters:: Characters that change the behavior of M4
@@ -488,6 +481,13 @@ Top
* Set manipulation Macros:: Set manipulation in M4
* Forbidden Patterns:: Catching unexpanded macros
+Programming in M4sh
+
+* Common Shell Constructs:: Portability layer for common shell constructs
+* Polymorphic Variables:: Support for indirect variable names
+* Initialization Macros:: Macros to establish a sane shell environment
+* File Descriptor Macros:: File descriptor macros for input and output
+
Writing Autoconf Macros
* Macro Definitions:: Basic format of an Autoconf macro
@@ -562,6 +562,14 @@ Top
* Floating Point Portability:: Portable floating-point arithmetic
* Exiting Portably::Exiting and the exit status
+Integer Overflow
+
+* Integer Overflow Basics:: Why integer overflow is a problem
+* Signed Overflow Examples::Examples of code assuming wraparound
+* Optimization and Wraparound:: Optimizations that break uses of wraparound
+* Signed Overflow Advice:: Practical advice for signed overflow issues
+* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
+
Manual Configuration
* Specifying Target Triplets:: Specifying target triplets
@@ -2410,7 +2418,7 @@ Makefile Substitutions
@menu
* Preset Output Variables:: Output variables that are always set
* Installation Directory Variables:: Other preset output variables
-* Changed Directory Variables:: Warnings about @file{datarootdir}
+* Changed Directory Variables:: Warnings about @file{datarootdir}
* Build Directories:: Supporting multiple concurrent compiles
* Automatic Remaking:: Makefile rules for configuring
@end menu
@@ -20445,11 +20453,11 @@ Integer Overflow
behavior that is commonly not implemented.
@menu
-* Integer Overflow Basics:: Why integer overflow is a problem
-* Signed Overflow Examples:: Examples of code assuming wraparound
+* Integer Overflow Basics:: Why integer overflow is a problem
+* Signed Overflow Examples::Examples of code assuming wraparound
* Optimization and Wraparound:: Optimizations that break uses of wraparound
-* Signed Overflow Advice:: Practical advice for signed overflow issues
-* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
+* Signed Overflow Advice:: Practical advice for signed overflow issues
+* Signed Integer Division:: @code{INT_MIN / -1} and @code{INT_MIN % -1}
@end menu
@node Integer Overflow Basics
Re: HP-UX make causes autoconf timestamp issues
* Eric Blake wrote on Mon, Jan 24, 2011 at 10:10:53PM CET:
On 01/24/2011 02:00 PM, Ralf Wildenhues wrote:
That is, is it only an autoconf bug,
where if you fix the autoconf bug, then all other victims will be fixed?
No. If you are building from a read-only tree, or, more generally, any
source tree that has been generated elsewhere and that is not supposed
to see updates, and the tree has rules that update shipped files, then
there are potentially problems with HP-UX make.
All the more reason to document the issue in INSTALL. If I'm
understanding you correctly, disabling autom4te.cache only disables
autoconf's contribution to the rebuild rules (others may remain, for
things like gperf- or yacc-generated files), but we might as well start
somewhere by documenting what we can.
You are of course completely right, thanks for persisting.
Let's drop the proposed BUGS change, add an install.texi one instead.
Together with my other hackishly written autoconf.texi patch I arrive
at this now.
Thanks, and sorry for the high noise ratio (I should also be cutting
down on cross posts again),
Ralf
2011-01-25 Ralf Wildenhues ralf.wildenh...@gmx.de
Eric Blake ebl...@redhat.com
docs: advise against HP-UX make due to time stamp semantics.
* doc/autoconf.texi (Timestamps and Make): Document HP-UX 11.31
make issue with targets having the same time stamps as their
prerequisites.
* doc/install.texi (Particular Systems): Warn against using
HP-UX make.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index ae601a0..61eb6f0 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -20287,6 +20287,14 @@ Timestamps and Make
date dest-stamp
@end example
+Apart from timestamp resolution, there are also differences in handling
+equal timestamps. HP-UX @command{make} updates targets if it has the
+same time stamp as one of its prerequisites, in violation of Posix rules.
+
+This can cause spurious rebuilds for repeated runs of @command{make}.
+This in turn can cause @command{make} to fail if it tries to rebuild
+generated files in a possibly read-only source tree with tools not
+present on the end-user machine. Use GNU @command{make} instead.
diff --git a/doc/install.texi b/doc/install.texi
index c43298b..d397b8a 100644
--- a/doc/install.texi
+++ b/doc/install.texi
@@ -261,6 +261,11 @@ Particular Systems
@noindent
and if that doesn't work, install pre-built binaries of GCC for HP-UX.
+HP-UX @command{make} updates targets which have the same time stamps as
+their prerequisites, which makes it generally unusable when shipped
+generated files such as @command{configure} are involved. Use GNU
+@command{make} instead.
+
On OSF/1 a.k.a.@: Tru64, some versions of the default C compiler cannot
parse its @code{wchar.h} header file. The option @option{-nodtk} can be
used as a workaround. If GNU CC is not installed, it is therefore
Re: parallel make and I/O of child processes
* Stefano Lattarini wrote on Tue, Jan 25, 2011 at 11:02:11AM CET:
So, what about the attached updated patch?
I have some nits, otherwise I'll let Eric approve this.
Subject: [PATCH] docs: another parallel make issue
* doc/autoconf.texi (Parallel Make): Document that some make
implementations, when run in parallel mode, connect stdout and
stderr of child processes to pipes or temporary files, and might
re-route stderr of spawned processes to stout. Also document
that FreeBSD make in parallel mode reuses the same shell for
multiple commands within one recipe (like NetBSD make does).
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19475,13 +19475,52 @@ sh
@cindex Parallel @command{make}
Support for parallel execution in @command{make} implementation varies.
-Generally, using GNU make is your best bet. When NetBSD
-@command{make} is invoked with @option{-j@var{N}}, it will reuse the
-same shell for multiple commands within one recipe. This can have
-unexpected consequences.@footnote{Note that GNU make has
-heuristics to avoid spawning a shell at all if the command is deemed
-safe to be executed directly.} For example, change of directories or
-variables persist between commands:
+Generally, using GNU make is your best bet.
+
+Some make implementations (among them, FreeBSD @command{make}, NetBSD
+@command{make}, and Solaris @command{dmake}), when invoked with a
+@option{-j@var{N}} option, connect the standard output and standard
+error of all their children processes to pipes or temporary regular
s/children/child/ (hasn't this been reviewed already?)
+files. This can lead to slightly but subtly different semantics in
s/slightly but//
+the behaviour of the spawned processes. For example, even if the
+@command{make} standard output is a connected to a tty, a command
s/is a/is/
+like @code{test -t 1} issued in a recipe will return a failure within
+those make implementations:
How about: ... is connected to a tty, the recipe commands will not be:
+@example
+$ @kbd{cat Makefile}
+all:
+@@test -t 1 echo Is a tty || echo Is not a tty
+$ @kbd{make -j 2} # FreeBSD make
+Is not a tty
+$ @kbd{make -j 2} # NetBSD make
+--- all ---
+Is not a tty
+$ @kbd{dmake -j 2} # Solaris dmake
+@var{hostname} -- 1 job
+@var{hostname} -- Job output
+Is not a tty
+@end example
+
+@noindent
+while on the other hand:
+
+@example
+$ @kbd{make -j 2} # GNU make, Heirloom make
+Is a tty
+@end example
+
+Furthermore, parallel run of those @command{make} implementations will
a parallel run or parallel runs
+route standard error from commands that they spawn into their own
s/that they spawn //
+standard output, and may remove leading whitespace from output lines.
+
+And there's more about NetBSD or FreeBSD @command{make}. When run in
This sentence is newspaper style. How about just
When NetBSD or FreeBSD @command{make} are run in parallel mode, ...
+parallel mode, they will reuse the same shell for multiple commands
+within one recipe. This can have unexpected
+consequences.@footnote{Note that GNU make has heuristics to avoid
+spawning a shell at all if the command is deemed safe to be executed
+directly.} For example, change of directories or variables persist
+between commands:
Footnotes are really ugly, we should think of them as costing 5 bucks or
so each time we use them. How about just omitting the footnote here,
since this isn't about GNU make otherwise at all? Also, I don't know
what the immediate connection here is.
FWIW, newish GNU make supports .ONESHELL for reusing shells between
recipe commands.
@example
all:
@@ -19518,12 +19557,9 @@ Another consequence of this is that, if one command
in a recipe uses
@code{exit 0} to indicate a successful exit, the shell will be gone
and the remaining commands of this recipe will not be executed.
-The above example also shows additional status output NetBSD
-@command{make} produces in parallel mode for targets being updated.
-
-Furthermore, parallel NetBSD @command{make} will route standard error
-from commands that it spawns into its own standard output, and may
-remove leading whitespace from output lines.
+The above example also shows additional status output produced by NetBSD
+@command{make}@footnote{but @emph{not} by FreeBSD @command{make}} in
I'd just replace the footnote with the same text in parentheses.
+parallel mode for targets being updated.
You can avoid these issues by using the @option{-B} option to enable
compatibility semantics. However, that will effectively also disable
Cheers,
Ralf
Re: Fix remake rule-induced test failures with HP-UX make.
* Ralf Wildenhues wrote on Sat, Jan 15, 2011 at 01:55:18PM CET:
http://autobuild.josefsson.org/automake/log-201101150749395803000.txt
docs: HP-UX make remakes targets with same time stamps as prereqs
* doc/autoconf.texi (Timestamps and Make): Document HP-UX 11.31
make issue with targets having the same time stamps as their
prerequisites.
Assuming this has been overlooked, ping!
While at it, how about appending some more info, as from the other
patch:
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -20183,7 +20183,9 @@ Timestamps and Make
date dest-stamp
@end example
-
+Apart from timestamp resolution, there are also differences in handling
+equal timestamps. HP-UX @command{make} updates targets if it has the
+same time stamp as one of its prerequisites, in violation of Posix rules.
+This can cause spurious rebuilds for repeated runs of @command{make}.
+This in turn can cause @command{make} to fail if it tries to rebuild
+generated files in a possibly read-only source tree with tools not
+present on the end-user machine. Use GNU @command{make} instead.
@c Portable C and C++ Programming
Re: parallel make and I/O of child processes
* Stefano Lattarini wrote on Mon, Jan 24, 2011 at 11:38:28PM CET: Subject: [PATCH] docs: another parallel make issue * doc/autoconf.texi (Parallel Make): Document that some make implementations, when run in parallel mode, connect stdout and stderr of child processes to pipes or temporary files. There are a couple of sentences about this further down in the same section: Furthermore, parallel NetBSD `make' will route standard error from commands that it spawns into its own standard output, and may remove leading whitespace from output lines. Can you fix them or merge them with your patch, so the topic isn't addressed in two separate locations in that section? Thanks, Ralf
whitespace and macros from the command line
Another patch set to document make limitations in autoconf.texi, and fix
the respective test failures in Automake. I have a separate patch for
Automake maint I'd like to apply, since this is such a long-standing
failure.
I'm not actually sure if Posix mandates the stripping of leading
whitespace from variables set on the make command line. I think
it does (which is why I chose that particular formulation), given
that leading whitespace is stripped after the equals sign in a
Makefile as well.
Any issues with this?
Thanks,
Ralf
Autoconf:
docs: new section about whitespace trimmmed from make command-lines.
* doc/autoconf.texi (Command-line Macros and whitespace): New
section, document trimming of whitespace from macros set on the
command line and from the environment.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 8a92ffd..8475ca8 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -535,6 +535,7 @@ Top
* Newlines in Make Rules:: Using literal newlines in rules
* Comments in Make Macros:: Other problems with Make comments in macros
* Trailing whitespace in Make Macros:: Macro substitution problems
+* Command-line Macros and whitespace:: Whitespace trimming of values
* obj/ and Make:: Don't name a subdirectory @file{obj}
* make -k Status:: Exit status of @samp{make -k}
* VPATH and Make:: @code{VPATH} woes
@@ -19141,6 +19142,7 @@ Portable Make
* Newlines in Make Rules:: Using literal newlines in rules
* Comments in Make Macros:: Other problems with Make comments in macros
* Trailing whitespace in Make Macros:: Macro substitution problems
+* Command-line Macros and whitespace:: Whitespace trimming of values
* obj/ and Make:: Don't name a subdirectory @file{obj}
* make -k Status:: Exit status of @samp{make -k}
* VPATH and Make:: @code{VPATH} woes
@@ -19646,6 +19648,26 @@ Trailing whitespace in Make Macros
@noindent
prints @samp{bar.test .test}.
+@node Command-line Macros and whitespace
+@section Command-line Macros and whitespace
+@cindex whitespace in command-line macros
+@cindex command-line, macros set on
+@cindex environment, macros set from
+
+Some @command{make} implementations may strip trailing whitespace off of
+macros set on the @command{make} command line in addition to leading
+whitespace. Further, some may strip leading whitespace off of macros
+set from environment variables:
+
+@example
+$ @kbd{echo 'print: ; @@echo x$(foo)x$(bar)x' |
+ foo=' f f ' make -f - bar=' b b '}
+x f f xb b x # AIX, BSD, GNU make
+xf f xb b x # HP-UX, IRIX, Tru64/OSF make
+x f f xb bx # Solaris make
+@end example
+
+
@node obj/ and Make
@section The @file{obj/} Subdirectory and Make
@cindex @file{obj/}, subdirectory
master:
tests: avoid instspc* failures due to make's whitespace trimming
* tests/instspc-tests.sh: Prepend './' when passing the test
characters, to avoid leading whitespace characters to be trimmed
from macros set from environment variables. Fixes testsuite
failures with HP-UX, IRIX, and Tru64/OSF make.
diff --git a/tests/instspc-tests.sh b/tests/instspc-tests.sh
index 38a63a4..1be8d0e 100755
--- a/tests/instspc-tests.sh
+++ b/tests/instspc-tests.sh
@@ -296,8 +296,12 @@ cd ./$build
../configure --prefix /$instspc_test_string-prefix
$MAKE
+# Some make implementations eliminate leading and trailing whitespace
+# from macros passed on the command line, and some eliminate leading
+# whitespace from macros set from environment variables, so prepend
+# './' and use the latter here.
# Tru64 sh -e needs '|| Exit' in order to work correctly.
-DESTDIR=$dest file=$instspc_test_string $MAKE -e test-install-sep \
+DESTDIR=$dest file=./$instspc_test_string $MAKE -e test-install-sep \
|| Exit 1
:
maint:
tests: avoid instspc.test failures due to make's whitespace trimming
* tests/instspc.test: Prepend './' when passing the test
characters, to avoid leading whitespace characters to be trimmed
from macros set from environment variables. Fixes testsuite
failures with HP-UX, IRIX, and Tru64/OSF make.
diff --git a/tests/instspc.test b/tests/instspc.test
index 414b3e5..7d00788 100755
--- a/tests/instspc.test
+++ b/tests/instspc.test
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2005, 2011 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -135,9 +135,13 @@ do
cd $build
+# Some make implementations eliminate leading and trailing whitespace
+# from macros passed on the command line, and some eliminate leading
+# whitespace from macros set from environment variables, so prepend
+# './' and use the latter here.
../configure --prefix /$file-prefix
$MAKE
-DESTDIR=$dest
HP-UX make causes autoconf timestamp issues
http://autobuild.josefsson.org/automake/log-201101181921247117000.txt
This HP-UX 11.31 system is fast enough to trigger test failures for
at least these Automake tests, besides the ones already fixed:
insthook
libobj16b
output10
posixsubst-data
posixsubst-scripts
subcond2
subpkg2
suffix13
all due to the bug that HP-UX make considers targets out of date when
they have the same time stamp as a prerequisite (cf. pending
autoconf.texi patch). The symptom is that autoconf is triggered during
`make distcheck' due to aclocal.m4 having same time stamp as configure,
which of course then fails in the read-only distdir tree:
+ make distcheck
[...]
CDPATH=${ZSH_VERSION+.}: cd .. /bin/sh
/tmp/build-ia64-hp-hpux11.31/tests/libobj16b.dir/libobj16b-1.0/missing --run
autoconf
autom4te: cannot create autom4te.cache: No such file or directory
Now, with even faster systems, that problem will only get worse over
time, i.e., happen in many more tests, and maybe also in user projects.
Question is what to do about it. Possibilities include:
- Add $sleep after every $ACLOCAL in problematic cases. Not
maintainable.
- sleep in aclocal, or even autom4te. Ugh!
- Let autom4te not fail if, in a read-only directory, autom4te.cache
creation fails but configure is actually up to date (seems doable,
but would probably require a number of changes in Autoconf).
- Work around it by using a global cache (not so good) or turning off
autom4te.cache creation completely, on HP-UX. Modify Autoconf to do
so by default, or at least recommend it?
The latter point deserves some explanation as to why I think it works:
autom4te updates an output file if at least one of its inputs is not
older than an existing output file. IOW, the semantics actually match
that of HP-UX make. Not using a cache means configure will be updated
at the first time $MAKE is run, and since files created after configure
are strictly newer than files created before, all will be well; at least
until one more dependency level is added to the bootstrap chain.
(Boy, am I glad gnulib-tool and aclocal are so slow.)
If a global autom4te.cache is used (which IIRC still has some bugs),
then autom4te will detect that configure doesn't change, but of course
time stamps persist in the problematic state, so several harmless but
time-consuming autoconf reruns will be triggered from within '$MAKE
distcheck'. So this works reliably, but is a bit suboptimal.
My question is, (how) should autotools cater to this HP-UX make wart?
Many users might use GNU make for their projects anyway, for them it
would not be nice to turn off caching outright.
Thus I suggest to document the issue, as below. I'm turning off
autom4te.cache for my future testing on this system.
Thanks,
Ralf
Recommend turning off autom4te.cache for HP-UX make.
* BUGS: Document HP-UX make bug causing failed autom4te.cache
creation during `make distcheck'.
diff --git a/BUGS b/BUGS
index 82c438e..6c95934 100644
--- a/BUGS
+++ b/BUGS
@@ -35,3 +35,8 @@ and use with caution an Autoconf with ``Important bugs''.
possible that other difficulties will be encountered, whether with
shell or platform limitations; help is appreciated in improving
parallel testsuite support.
+
+* The non-Posix time stamp semantics of HP-UX make can cause Automake's
+ `make distcheck' to fail due to failed autom4te.cache directory creation.
+ It is recommended to turn off autom4te caching on these systems if GNU
+ make cannot be used (see info Autoconf 'Customizing autom4te').
trailing whitespace in make macros (was: bug#7868: splitting up test suites)
[ moving from automake bug#7868 ]
* Ralf Wildenhues wrote on Sat, Jan 22, 2011 at 11:06:48AM CET:
* Stefano Lattarini wrote on Thu, Jan 20, 2011 at 10:19:24PM CET:
On Thursday 20 January 2011, Ralf Wildenhues wrote:
That is the reason the check-TESTS rule is so ugly (and recursive) in
the first place. I really would like to avoid more instances of this
wart; so specifying files without extension is Not Good(TM).
OK, noted (and these considerations could IMHO end up somewhere in the
manual).
Good suggestion. They should be mentioned in the portability section of
autoconf.texi if they aren't already, and as ## comments in check.am.
Proposed patches for Automake maint and Autoconf below.
Thanks,
Ralf
Add comment to check-TESTS rule working around make 3.80 bug.
* lib/am/check.am (check-TESTS): Update comment.
Suggestion by Stefano Lattarini.
diff --git a/lib/am/check.am b/lib/am/check.am
index 5728081..d792372 100644
--- a/lib/am/check.am
+++ b/lib/am/check.am
@@ -235,6 +235,9 @@ check-TESTS:
## OTOH, this means that, in the rule for `$(TEST_SUITE_LOG)', we
## cannot use `$?' to compute the set of lazily rerun tests, lest
## we rely on .PHONY to work portably.
+##
+## Work around a GNU make 3.80 bug expanding trailing whitespace in
+## `TESTS = foo.test $(empty)' to `foo.log .log' in $(TESTS_LOGS).
@test -z $(TEST_SUITE_LOG) || rm -f $(TEST_SUITE_LOG)
@list='$(TEST_LOGS)'; \
list=`for f in $$list; do \
docs: new sections about macros and comments, substitutions.
* doc/autoconf.texi (Top, Portable Make): Adjust menus.
(Comments in Make Macros, Trailing whitespace in Make Macros):
New sections.
Suggestion by Stefano Lattarini.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index eee4ba7..0e8c3cc 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -533,6 +533,8 @@ Portable Make Programming
* Parallel Make:: Parallel @command{make} quirks
* Comments in Make Rules:: Other problems with Make comments
* Newlines in Make Rules:: Using literal newlines in rules
+* Comments in Make Macros:: Other problems with Make comments in macros
+* Trailing whitespace in Make Macros:: Macro substitution problems
* obj/ and Make:: Don't name a subdirectory @file{obj}
* make -k Status:: Exit status of @samp{make -k}
* VPATH and Make:: @code{VPATH} woes
@@ -19135,6 +19137,8 @@ itself.
* Parallel Make:: Parallel @command{make} quirks
* Comments in Make Rules:: Other problems with Make comments
* Newlines in Make Rules:: Using literal newlines in rules
+* Comments in Make Macros:: Other problems with Make comments in macros
+* Trailing whitespace in Make Macros:: Macro substitution problems
* obj/ and Make:: Don't name a subdirectory @file{obj}
* make -k Status:: Exit status of @samp{make -k}
* VPATH and Make:: @code{VPATH} woes
@@ -19575,6 +19579,55 @@ nlinit=`echo 'nl='; echo ''`; eval $$nlinit; \
sed -e s/\$$/\\$$@{nl@}/ input output
@end example
+@node Comments in Make Macros
+@section Comments in Make Macros
+@cindex Comments in @file{Makefile} macros
+@cindex @file{Makefile} macros and comments
+
+Avoid putting comments in macro values as far as possible. Posix
+specifies that the text starting from the @samp{#} sign until the end of
+the line is to be ignored, which has the unfortunate effect of
+disallowing them even quoted. Thus, the following might lead to a
+syntax error at compile time:
+
+@example
+CPPFLAGS = -DCOMMENT_CHAR='#'
+@end example
+
+@noindent
+as @samp{CPPFLAGS} may be expanded to @samp{-DCOMMENT_CHAR='#}.
+Luckily, most @command{make} implementations disregard this and treat
+single and double quotes specially here.
+
+Even without quoting involved, comments can have surprising effects,
+because the whitespace before them is part of the variable value:
+
+@example
+foo = bar # trailing comment
+print: ; @@echo $(foo).
+@end example
+
+@noindent
+prints @samp{bar .}, which is usually not intended, and can expose
+@command{make} bugs as described below.
+
+@node Trailing whitespace in Make Macros
+@section Trailing whitespace in Make Macros
+@cindex whitespace in @file{Makefile} macros
+@cindex @file{Makefile} macros and whitespace
+
+GNU @command{make} 3.80 mistreats trailing whitespace in macro
+substitutions and appends another spurious suffix:
+
+@example
+empty =
+foo = bar $(empty)
+print: ; @@echo $(foo:=.test)
+@end example
+
+@noindent
+prints @samp{bar.test .test}.
+
@node obj/ and Make
@section The @file{obj/} Subdirectory and Make
@cindex @file{obj/}, subdirectory
Re: trailing whitespace in make macros
* Stefano Lattarini wrote on Sat, Jan 22, 2011 at 12:14:27PM CET:
On Saturday 22 January 2011, Ralf Wildenhues wrote:
docs: new sections about macros and comments, substitutions.
Why the comma after comments? Has the sentence got borked somehow?
It's supposed to be a two-item list, `comments and substitutions',
shortened from `macros and comments, and macros and substitutions'.
I've changed it to
docs: new sections about comments and whitespace in make macros.
now, that should be clearer.
* doc/autoconf.texi (Top, Portable Make): Adjust menus.
(Comments in Make Macros, Trailing whitespace in Make Macros):
New sections.
Suggestion by Stefano Lattarini.
[...]
+@example
+CPPFLAGS = -DCOMMENT_CHAR='#'
+@end example
+
+@noindent
+as @samp{CPPFLAGS} may be expanded to @samp{-DCOMMENT_CHAR='#}.
You mean @samp{-DCOMMENT_CHAR='} here?
Yep, fixed in my local copy.
Thanks for the quick review!
Ralf
avoid buggy AIX 5.3 cp -R.
automake/tests/fn99{,subdir}.test have been long-time failures on
AIX 5.[123], but not 6.1 or newer (and IIRC not 4.3.3 either):
http://autobuild.josefsson.org/automake/log-201101181921915482000.txt
| + make distcheck
| make dist-gzip am__post_remove_distdir='@:'
| { test ! -d fn99-1.0 || { find fn99-1.0 -type d ! -perm -200
-exec chmod u+w {} ';' rm -fr fn99-1.0; }; }
| test -d fn99-1.0 || mkdir fn99-1.0
| cp: 8???: A file or directory in the path name does not exist.
| make: 1254-004 The error code from the last command is 1.
I finally got myself to look at this a bit, and playing around with
various directory depths and whether there are files in them, I can only
come to the conclusion that this system's cp -R is simply unusable as it
corrupts its memory depending on the source tree layout. I've even got
it to dump core.
Any reasons against these two patches, for Autoconf master and Automake
maint?
It might be possible to rework the distdir rule to use maybe
tar cBf - files | (cd $(distdir) tar xf -)
but that opens up its own set of problems (are ACLs copied? is the
sub-second time stamp handling the same as that of cp?) I'm not eager
to pursue this unless we see a real-life bug report from somebody who
needs it to work on AIX.
Thanks,
Ralf
docs: do not use AIX 5.3 cp -R.
* doc/autoconf.texi (Limitations of Usual Tools): Document one
instance of the cp -R bug on AIX 5.3. This seems to have been
fixed in 6.1 and newer releases.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 4cb3a8c..eee4ba7 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -18065,7 +18065,16 @@ Avoid the @option{-r} option, since Posix 1003.1-2004
marks it as
obsolescent and its behavior on special files is implementation-defined.
Use @option{-R} instead. On GNU hosts the two options
are equivalent, but on Solaris hosts (for example) @code{cp -r}
-reads from pipes instead of replicating them.
+reads from pipes instead of replicating them. AIX 5.3 @code{cp -R} may
+corrupt its own memory with some directory hierarchies and error out or
+dump core:
+
+@example
+@kbd{mkdir -p 12345678/12345678/12345678/12345678}
+@kbd{touch 12345678/12345678/x}
+@kbd{cp -R 12345678 t}
+cp: 0653-440 12345678/12345678/: name too long.
+@end example
Some @command{cp} implementations (e.g., BSD/OS 4.2) do not allow
trailing slashes at the end of nonexistent destination directories. To
tests: avoid fn99*.test failures due to buggy AIX 5.3 cp -R.
* tests/fn99.test, tests/fn99subdir.test: Skip if an initial
`cp -R' of the subdir tree already fails; AIX 5.3 cp messes
up its internal memory when copying this tree.
diff --git a/tests/fn99.test b/tests/fn99.test
index e80d09f..c2afd2e 100755
--- a/tests/fn99.test
+++ b/tests/fn99.test
@@ -32,6 +32,9 @@ do
touch x
done) || Exit 77
+# AIX 5.3 `cp -R' is too buggy for `make dist'.
+cp -R 12345678 t || Exit 77
+
$ACLOCAL
$AUTOCONF
$AUTOMAKE
diff --git a/tests/fn99subdir.test b/tests/fn99subdir.test
index 0f05b5a..a040e58 100755
--- a/tests/fn99subdir.test
+++ b/tests/fn99subdir.test
@@ -53,6 +53,9 @@ do
touch x
done)
+# AIX 5.3 `cp -R' is too buggy for `make dist'.
+cp -R ${subdirname} t || Exit 77
+
for init_dir in ${subdirname} .; do
(
cd ${init_dir} || Exit 1
Re: avoid buggy AIX 5.3 cp -R.
Hi Eric,
* Eric Blake wrote on Sat, Jan 22, 2011 at 02:46:29PM CET:
On 01/22/2011 05:45 AM, Ralf Wildenhues wrote:
automake/tests/fn99{,subdir}.test have been long-time failures on
AIX 5.[123], but not 6.1 or newer (and IIRC not 4.3.3 either):
http://autobuild.josefsson.org/automake/log-201101181921915482000.txt
+@example
+@kbd{mkdir -p 12345678/12345678/12345678/12345678}
+@kbd{touch 12345678/12345678/x}
+@kbd{cp -R 12345678 t}
+cp: 0653-440 12345678/12345678/: name too long.
+@end example
Does 'cp -r' fare any better (not that it's a good solution, because it
can hang on pipes)?
Nope, at least not on AIX 5.3. I rechecked 5.1 now, and while the
Automake test segfaulted there, the exact sequence from the
autoconf.texi patch does not fail there now. Oh well, memory
corruption is a tricky beast, I'm not really motivated to find a
case that fails identically on all three systems.
At any rate, this is fine for the autoconf manual.
Thanks,
Ralf
Re: trailing whitespace in make macros
* Eric Blake wrote on Sat, Jan 22, 2011 at 03:03:02PM CET:
Should we also mention the converse issue of non-comments? That is,
Posix requires that # embedded in the middle of a rule (and not a macro)
is okay. Which is why gnulib's include-next module works [...]
Yes, sure. There already exists a node Comments in Make Rules,
so it would fit there, with appropriate cross-references. OK?
Eventually, the chapter might benefit from a bit of reordering,
but this too, can be done later in a separate patch I think.
Thanks,
Ralf
docs: document how to use comment characters in rules.
* doc/autoconf.texi (Comments in Make Rules): Explain how to
produce a `#' in a rule.
(Comments in Make Macros): Add cross reference.
Suggestion from Eric Blake.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 110f5f5..8a92ffd 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -19553,6 +19553,21 @@ Comments in Make Rules
: foo
@end example
+Conversely, if you want to use the @samp{#} character in some command,
+you can only do so by expanding it inside a rule (@pxref{Comments in
+Make Macros}). So for example, if @samp{COMMENT_CHAR} is substituted by
+@command{config.status} as @samp{#}, then the following substitutes
+@samp{@@COMMENT_CHAR@@} in a generated header:
+
+@example
+foo.h: foo.h.in
+sed -e 's|@@''COMMENT_CHAR''@@|@@COMMENT_CHAR@@|g' \
+$(srcdir)/foo.h.in $@@
+@end example
+
+The funny shell quoting avoids a substitution at @command{config.status}
+run time of the left-hand side of the @command{sed} @samp{s} command.
+
@node Newlines in Make Rules
@section Newlines in Make Rules
@cindex Newlines in @file{Makefile} rules
@@ -19599,7 +19614,8 @@ Comments in Make Macros
@noindent
as @samp{CPPFLAGS} may be expanded to @samp{-DCOMMENT_CHAR='}.
Luckily, most @command{make} implementations disregard this and treat
-single and double quotes specially here.
+single and double quotes specially here; @pxref{Comments in Make Rules},
+for a more portable alternative.
Even without quoting involved, comments can have surprising effects,
because the whitespace before them is part of the variable value:
Fix LEXLIB and YYTEXT_POINTER with IRIX 6.5 flex 2.5.4.
http://autobuild.josefsson.org/automake/log-201101181921817456000.txt
On IRIX, the code from AC_PROG_LEX sees something like this:
$ cc -o conf lex.yy.c -ll
cc-1042 cc: ERROR File = conf.l, Line = 6
The types of operands char * and int are incompatible.
{ yyless (input () != 0); }
^
caused by something ugly like this:
| #define yyless(n) \
| do \
| { \
| /* Undo effects of setting up yytext. */ \
| *yy_cp = yy_hold_char; \
| YY_RESTORE_YY_MORE_OFFSET \
| yy_c_buf_p = yy_cp = yy_bp + n - YY_MORE_ADJ; \
| YY_DO_BEFORE_ACTION; /* set up yytext again */ \
| } \
| while ( 0 )
|
[...]
| /* Redefine yyless() so it works in section 3 code. */
|
| #undef yyless
| #define yyless(n) \
| do \
| { \
| /* Undo effects of setting up yytext. */ \
| yytext[yyleng] = yy_hold_char; \
| yy_c_buf_p = yytext + n; \
| yy_hold_char = *yy_c_buf_p; \
| *yy_c_buf_p = '\0'; \
| yyleng = n; \
| } \
| while ( 0 )
which in turn causes an Automake test failure.
OK to push the fix below, even if it's to work around decade
old bugs?
Thanks,
Ralf
Fix LEXLIB and YYTEXT_POINTER with IRIX 6.5 flex 2.5.4.
* lib/autoconf/programs.m4 (_AC_PROG_LEX_YYTEXT_DECL):
Overquote nontrivial yyless argument, to compensate for
underquoted macro definition in IRIX 6.5 flex 2.5.4
leading to compile failure due to incompatible operands.
Fixes Automake silent-lex-generic.test failure.
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index 0def8b2..fb3d8b9 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -724,7 +724,8 @@ a { ECHO; }
b { REJECT; }
c { yymore (); }
d { yyless (1); }
-e { yyless (input () != 0); }
+e { /* IRIX 6.5 flex 2.5.4 underquotes its yyless argument. */
+yyless ((input () != 0)); }
f { unput (yytext[0]); }
. { BEGIN INITIAL; }
%%
Tru64 sh treats read as special builtin
First off, please consider this squashed in with my previous patch:
@@ -20184,7 +20186,7 @@ Timestamps and Make
@end example
Apart from timestamp resolution, there are also differences in handling
-equal timestamps. HP-UX @command{make} updates targets if it has the
+equal timestamps. HP-UX @command{make} updates a target if it has the
same time stamp as one of its prerequisites, in violation of Posix rules.
Then, ok to apply the patch below as well? sh exits upon
read line unreadable
or
read line nonexistent
Luckily, ksh doesn't do this, otherwise libtool would've been in
trouble.
Thanks,
Ralf
docs: Tru64/OSF sh treats read as special builtin
* doc/autoconf.texi (Limitations of Builtins): read may exit
upon unreadable or non-existent file with Tru64/OSF 5.1 sh.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 0e9f0ea..a19c352 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17342,7 +17342,9 @@ Limitations of Builtins
@c -
@prindex @command{read}
No options are portable, not even support @option{-r} (Solaris
-@command{/bin/sh} for example).
+@command{/bin/sh} for example). Tru64/OSF 5.1 @command{sh} treats
+@command{read} as a special built-in, so it may exit if input is
+redirected from a non-existent or unreadable file.
@anchor{set}
Re: Fix remake rule-induced test failures with HP-UX make.
[ adding autoconf-patches ]
* Ralf Wildenhues wrote on Sat, Jan 15, 2011 at 11:31:55AM CET:
Quoting parts of:
http://autobuild.josefsson.org/automake/log-201101150749395803000.txt
I'm not quite sure why HP-UX make seems to trigger rebuild rules for
prerequisites that have the exact time stamps as targets (in this case,
config.status and subdir Makefile, but I also tried with a reduced
makefile), but it is not Posix conforming. Working around it properly
would probably require sleeping inside config.status (an obvious no-go),
and in practice it should not do more harm than updating some rules more
than necessary.
Found it documented in HP-UX/IA 11.31 make(1):
If no target names are specified on the command line, make updates the
first target in the (first) makefile that is not an inference rule. A
target is updated in two cases: firstly, if it depends on files that
are newer than the target; secondly, if it depends on files that have
same modification time as that of the target. Missing files are
deemed to be out-of-date. [...]
Anybody have a support contract to report this Posix violation upstream?
OK to commit?
Thanks,
Ralf
docs: HP-UX make remakes targets with same time stamps as prereqs
* doc/autoconf.texi (Timestamps and Make): Document HP-UX 11.31
make issue with targets having the same time stamps as their
prerequisites.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 9f5494e..81664e4 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -20183,7 +20183,9 @@ Timestamps and Make
date dest-stamp
@end example
-
+Apart from timestamp resolution, there are also differences in handling
+equal timestamps. HP-UX @command{make} updates targets if it has the
+same time stamp as one of its prerequisites, in violation of Posix rules.
@c Portable C and C++ Programming
Re: [FYI] docs: cygnus mode doesn't require AM_CYGWIN32 macro.
[ replacing automake-patches with autoconf-patches ] tying up another loose end: * Ralf Wildenhues wrote on Wed, Dec 22, 2010 at 07:22:24AM CET: Hmpf. Nowadays AM_CYGWIN just expands to AC_CYGWIN, which causes $CYGWIN to be set. The latter is probably a bad idea for other reasons (Cygwin AFAIK uses the variable for other purposes), but at least one macro in Autoconf's fortran.m4 still seems to make use of $CYGWIN. It should at least also be fixed to use $host_os instead. The patch below should address that. I have no idea whether this code is still relevant on Cygwin, but I'm assuming that it is. I haven't actually tested it there, but I'm running the testsuite on GNU/Linux right now to ensure there are no undesired side effects. OK to push when that passes? Thanks, Ralf Avoid reference to $CYGWIN in Fortran macros. * lib/autoconf/fortran.m4 (_AC_FC_LIBRARY_LDFLAGS): Require AC_CANONICAL_HOST. Replace test for $CYGWIN with $host_s test. diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index c704868..bed9c96 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/fortran.m4 @@ -609,7 +609,8 @@ fi], # in octave-2.0.13/aclocal.m4, and full credit should go to John # W. Eaton for writing this extremely useful macro. Thank you John. AC_DEFUN([_AC_FC_LIBRARY_LDFLAGS], -[_AC_FORTRAN_ASSERT()dnl +[AC_REQUIRE([AC_CANONICAL_HOST])dnl +_AC_FORTRAN_ASSERT()dnl _AC_PROG_FC_V AC_CACHE_CHECK([for _AC_LANG libraries of $[]_AC_FC[]], ac_cv_[]_AC_LANG_ABBREV[]_libs, [if test x$[]_AC_LANG_PREFIX[]LIBS != x; then @@ -641,7 +642,11 @@ while test $...@%:@] != 1; do |-LANG:=* | -LIST:* | -LNO:* | -link) ;; -lkernel32) - test x$CYGWIN != xyes ac_cv_[]_AC_LANG_ABBREV[]_libs=$ac_cv_[]_AC_LANG_ABBREV[]_libs $ac_arg + case $host_os in + *cygwin*) ;; + *) ac_cv_[]_AC_LANG_ABBREV[]_libs=$ac_cv_[]_AC_LANG_ABBREV[]_libs $ac_arg + ;; + esac ;; -[[LRuYz]]) # These flags, when seen by themselves, take an argument.
Re: configmake doc?
* Karl Berry wrote on Mon, Jan 10, 2011 at 01:36:51AM CET:
(Eric/Ralf, you can add a specific reference to the new configmake
node from the Automake/Autoconf manuals now if you wish.)
Done.
Thanks,
Ralf
docs: link to Gnulib configmake documentation.
* doc/autoconf.texi (Defining Directories): Use proper crossref,
now that the Gnulib manual has a configmake section.
Thanks to Karl Berry.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 3b7fde6..b999f03 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24945,7 +24945,8 @@ Defining Directories
@noindent
The gnulib module @samp{configmake} provides such a header with all the
-standard directory variables defined, @pxref{Gnulib}.
+standard directory variables defined, @pxref{configmake,,, gnulib, GNU
+Gnulib}.
@item
Use @code{AC_DEFINE} but have @command{configure} compute the literal
Re: bug#7773: (lack of) config.h description in manual
[ adding autoconf-patches, dropping the Automake bug ]
* Eric Blake wrote on Tue, Jan 04, 2011 at 01:33:42AM CET:
I also agree that the autoconf manual should mention the gnulib
'configmake' module (it doesn't, yet).
Proposed patch. OK to push?
I didn't find a place in the gnulib manual where configmake was
explained.
Thanks,
Ralf
docs: mention configmake module for defining directories.
* doc/autoconf.texi (Defining Directories): Mention configmake
gnulib module.
Suggestion by Karl Berry and Eric Blake.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 5fbfb79..54891b6 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24944,6 +24944,10 @@ Defining Directories
echo '#define DATADIR $(datadir)' $@@
@end example
+...@noindent
+The gnulib module @samp{configmake} provides such a header with all the
+standard directory variables defined, @pxref{Gnulib}.
+
@item
Use @code{AC_DEFINE} but have @command{configure} compute the literal
value of @code{datadir} and others. Many people have wrapped macros to
Re: [PATCH] {master} Tests: normalize use of the 'errexit' shell flag.
[ adding -patches ]
* Eric Blake wrote on Mon, Jan 03, 2011 at 10:22:32PM CET:
[redirecting to bug-autoconf]
On 01/03/2011 02:17 PM, Ralf Wildenhues wrote:
These two were added by me in fear of shells resetting errexit upon
function entry (like some shells do with -x aka xtrace). Luckily I
couldn't find any shells which do this upon testing (by looking for 'e'
in the output of)
sh -ec 'f () { echo $-; }; f'
but generally, here's a nice (and more complete than autoconf.texi) list
of issues with set -e: http://www.in-ulm.de/~mascheck/various/set-e/
Awesome reference - the autoconf manual should probably mention it.
Yep. While at it, I cannot find this link we already have in the
manual:
http://www.opengroup.org/austin/mailarchives/ag-review/msg03507.html
Did it vanish, or is this only viewable with an account or so?
If we can find and correct it; I suggest the first patch below,
otherwise the second. OK to push?
Thanks,
Ralf
docs: link to 'set -e' shell behavior overview.
* doc/autoconf.texi (Limitations of Builtins): Add link to
Sven Mascheck's 'set -e' page.
Suggestion by Eric Blake.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index be1ef5b..ef32295 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17382,7 +17382,9 @@ Limitations of Builtins
@cindex @command{set -e}
The option @option{-e} has historically been underspecified, with enough
ambiguities to cause numerous differences across various shell
-implementations. Perhaps the best reference is
+implementations; see for example
+...@uref{http://www.in-ulm.de/@/~mascheck/@/various/@/set-e/, this overview},
+or
@uref{http://www.opengroup.org/@/austin/@/mailarchives/@/ag-review/@/msg03507.html,
this link}, recommending a change to Posix 2008 to match @command{ksh88}
behavior. Note that mixing @code{set -e} and shell functions is asking
docs: link to 'set -e' shell behavior overview.
* doc/autoconf.texi (Limitations of Builtins): Add link to
Sven Mascheck's 'set -e' page. Remove broken Opengroup link.
Suggestion by Eric Blake.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index be1ef5b..b2acabb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17382,11 +17382,9 @@ Limitations of Builtins
@cindex @command{set -e}
The option @option{-e} has historically been underspecified, with enough
ambiguities to cause numerous differences across various shell
-implementations. Perhaps the best reference is
-...@uref{http://www.opengroup.org/@/austin/@/mailarchives/@/ag-review/@/msg03507.html,
-this link}, recommending a change to Posix 2008 to match @command{ksh88}
-behavior. Note that mixing @code{set -e} and shell functions is asking
-for surprises:
+implementations; see for example
+...@uref{http://www.in-ulm.de/@/~mascheck/@/various/@/set-e/, this overview}.
+Note that mixing @code{set -e} and shell functions is asking for surprises:
@example
set -e
Re: [PATCH] {master} Tests: normalize use of the 'errexit' shell flag.
* Eric Blake wrote on Sat, Jan 08, 2011 at 10:40:11PM CET:
If we can find and correct it; I suggest the first patch below,
otherwise the second. OK to push?
Let's go with a third option - start with the second,
docs: link to 'set -e' shell behavior overview.
* doc/autoconf.texi (Limitations of Builtins): Add link to
Sven Mascheck's 'set -e' page. Remove broken Opengroup link.
Suggestion by Eric Blake.
but rather than deleting the broken Opengroup link, replace it with the
working link to the latest POSIX wording:
http://www.austingroupbugs.net/view.php?id=52
Thanks for getting to it before me, and pre-approved to push once you
make that change.
Thanks for the research and review. Incorporating the above link, I
ended up more or less going with my first proposed patch. This is what
I'm pushing now, feel free to improve if you like.
Cheers,
Ralf
docs: link to 'set -e' shell behavior overview.
* doc/autoconf.texi (Limitations of Builtins): Add link to
Sven Mascheck's 'set -e' page. Replace broken Opengroup link.
Suggestion by Eric Blake.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index be1ef5b..3b7fde6 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -17382,11 +17382,11 @@ Limitations of Builtins
@cindex @command{set -e}
The option @option{-e} has historically been underspecified, with enough
ambiguities to cause numerous differences across various shell
-implementations. Perhaps the best reference is
-...@uref{http://www.opengroup.org/@/austin/@/mailarchives/@/ag-review/@/msg03507.html,
-this link}, recommending a change to Posix 2008 to match @command{ksh88}
-behavior. Note that mixing @code{set -e} and shell functions is asking
-for surprises:
+implementations; see for example
+...@uref{http://www.in-ulm.de/@/~mascheck/@/various/@/set-e/, this overview},
+or @uref{http://www.austingroupbugs.net/@/view.php?id=52, this link},
+documenting a change to Posix 2008 to match @command{ksh88} behavior.
+Note that mixing @code{set -e} and shell functions is asking for surprises:
@example
set -e
Re: [PATCH 1/2] maint: new rule to update copyright year ranges
Hi Karl,
* Karl Berry wrote on Mon, Jan 03, 2011 at 12:58:23AM CET:
And, does anyone mind if I remove the @acronym commands from
install.texi, per our too-long prior discussion?
FWIW, I don't mind, but please do it in upstream Autoconf.
I don't currently have write permission in autoconf. I could give it to
myself :), but would you mind just doing it instead, since it's such a
trivial change? (removing @acronym; BTW, @acronym{GNU} is the only
one.)
I'm applying this in your name.
Cheers,
Ralf
2011-01-03 Karl Berry k...@free...
Avoid using @acronym in install.texi.
* doc/install.texi (Basic Installation, Multiple Architectures)
(Installation Names): Write `GNU' instead of `...@acronym{gnu}'.
diff --git a/doc/install.texi b/doc/install.texi
index 6dd4a57..a220458 100644
--- a/doc/install.texi
+++ b/doc/install.texi
@@ -7,7 +7,7 @@
@unnumbered Installation Instructions
Copyright @copyright{} 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004,
-2005, 2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+2005, 2006, 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification, are
permitted in any medium without royalty provided the copyright notice
@@ -28,9 +28,9 @@ Basic Installation
of the features documented below. The lack of an optional feature in a
given package is not necessarily a bug.
@end ifclear
-More recommendations for @acronym{GNU} packages can be found in
+More recommendations for GNU packages can be found in
@ref{Makefile Conventions, , Makefile Conventions, standards,
-...@acronym{gnu} Coding Standards}.
+GNU Coding Standards}.
The @command{configure} shell script attempts to guess correct values
for various system-dependent variables used during compilation. It uses
@@ -103,7 +103,7 @@ Basic Installation
Often, you can also type @samp{make uninstall} to remove the installed
files again. In practice, not all packages have tested that
uninstallation works correctly, even though it is required by the
-...@acronym{gnu} Coding Standards.
+GNU Coding Standards.
@item
Some packages, particularly those that use Automake, provide @samp{make
@@ -135,14 +135,14 @@ Multiple Architectures
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
-own directory. To do this, you can use @acronym{GNU} @command{make}.
+own directory. To do this, you can use GNU @command{make}.
@command{cd} to the directory where you want the object files and
executables to go and run the @command{configure} script.
@command{configure} automatically checks for the source code in the
directory that @command{configure} is in and in @file{..}. This is
known as a @dfn{VPATH} build.
-With a n...@acronym{gnu} @command{make},
+With a non-GNU @command{make},
it is safer to compile the package for one
architecture at a time in the source code directory. After you have
installed the package for one architecture, use @samp{make distclean}
@@ -204,16 +204,16 @@ Installation Names
@command{configure}, but not in terms of @sam...@{prefix@}}, must each be
overridden at install time for the entire
installation to be relocated. The approach of makefile variable
-overrides for each directory variable is required by the @acronym{GNU}
+overrides for each directory variable is required by the GNU
Coding Standards, and ideally causes no recompilation. However, some
platforms have known limitations with the semantics of shared libraries
that end up requiring recompilation when using this method, particularly
-noticeable in packages that use @acronym{GNU} Libtool.
+noticeable in packages that use GNU Libtool.
The second method involves providing the @samp{DESTDIR} variable. For
example, @samp{make install DESTDIR=/alternate/directory} will prepend
@samp{/alternate/directory} before all installation names. The approach
-of @samp{DESTDIR} overrides is not required by the @acronym{GNU} Coding
+of @samp{DESTDIR} overrides is not required by the GNU Coding
Standards, and does not work on platforms that have drive letters. On
the other hand, it does better at avoiding recompilation issues, and
works well even when some directory options were not specified in terms
Re: [PATCH] Document AC_FUNC_FORK cache variables
Hello Colin,
* Colin Watson wrote on Mon, Dec 20, 2010 at 12:33:46AM CET:
I maintain a package where I'd like to fail at configure time if fork
doesn't work. This is slightly awkward because 'info autoconf' doesn't
document the cache variables for AC_FUNC_FORK, so I don't know whether I
can rely on them in future versions of Autoconf. Would you be willing
to document them as follows and thereby promise that they will continue
to work?
The reason we didn't document them right away was because the semantics
are a bit more complex: while you can read the results in these
variables, you cannot override the test completely by setting these
variables. ac_cv_func_fork and ac_cv_func_vfork are also involved.
We could change the macro so that the _works variables are not
overridden when set, or just document the need to also set the
other two. Below is a (fairly untested) patch for the former
(4 new lines plus large reindent). However, this still differs
in configure output (the _works result is not communicated in the
cache case) so I'm not sure this is the better approach.
Probably easier to append In order to override the test, you also
need to set the @code{ac_cv_func_fork} and @code{ac_cv_func_vfork}
variables. Eric?
Thanks,
Ralf
2010-12-20 Ralf Wildenhues ralf.wildenh...@gmx.de
Fix AC_FUNC_FORK to not override pre-set cache variables.
* lib/autoconf/functions.m4 (AC_FUNC_FORK): Do not recompute
ac_cv_func_fork_works or ac_cv_func_vfork_works if they are
already set by the user.
Prompted by report from Colin Watson.
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index f2048bf..1f2c5e7 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1791,30 +1791,34 @@ AC_DEFUN([AC_FUNC_FORK],
[AC_REQUIRE([AC_TYPE_PID_T])dnl
AC_CHECK_HEADERS(vfork.h)
AC_CHECK_FUNCS(fork vfork)
-if test x$ac_cv_func_fork = xyes; then
- _AC_FUNC_FORK
-else
- ac_cv_func_fork_works=$ac_cv_func_fork
-fi
-if test x$ac_cv_func_fork_works = xcross; then
- case $host in
-*-*-amigaos* | *-*-msdosdjgpp*)
- # Override, as these systems have only a dummy fork() stub
- ac_cv_func_fork_works=no
- ;;
-*)
- ac_cv_func_fork_works=yes
- ;;
- esac
- AC_MSG_WARN([result $ac_cv_func_fork_works guessed because of cross
compilation])
+if test ${ac_cv_func_fork_works+set} != set; then
+ if test x$ac_cv_func_fork = xyes; then
+_AC_FUNC_FORK
+ else
+ac_cv_func_fork_works=$ac_cv_func_fork
+ fi
+ if test x$ac_cv_func_fork_works = xcross; then
+case $host in
+ *-*-amigaos* | *-*-msdosdjgpp*)
+ # Override, as these systems have only a dummy fork() stub
+ ac_cv_func_fork_works=no
+ ;;
+ *)
+ ac_cv_func_fork_works=yes
+ ;;
+esac
+AC_MSG_WARN([result $ac_cv_func_fork_works guessed because of cross
compilation])
+ fi
fi
-ac_cv_func_vfork_works=$ac_cv_func_vfork
-if test x$ac_cv_func_vfork = xyes; then
- _AC_FUNC_VFORK
-fi;
-if test x$ac_cv_func_fork_works = xcross; then
+if test ${ac_cv_func_vfork_works+set} != set; then
ac_cv_func_vfork_works=$ac_cv_func_vfork
- AC_MSG_WARN([result $ac_cv_func_vfork_works guessed because of cross
compilation])
+ if test x$ac_cv_func_vfork = xyes; then
+_AC_FUNC_VFORK
+ fi;
+ if test x$ac_cv_func_fork_works = xcross; then
+ac_cv_func_vfork_works=$ac_cv_func_vfork
+AC_MSG_WARN([result $ac_cv_func_vfork_works guessed because of cross
compilation])
+ fi
fi
if test x$ac_cv_func_vfork_works = xyes; then
Re: PATCH RFA: Add support for Go programming language
* Eric Blake wrote on Wed, Nov 03, 2010 at 06:42:54PM CET: On 11/03/2010 11:38 AM, Ian Lance Taylor wrote: It otherwise seems low-danger to me, but I wouldn't want to move forward on the Libtool sister patch without this one cleared. I'm at the point with my gcc patches where I kind of need an answer to this question. The question is: what name should we use in shell and make to refer to the Go compiler? I've been using GCCGO. Should we instead use GOC or GOCC or something else? How can we decide this? Personally, I'd like GOC mnemonic of Go-compiler (to match FC for Fortran-compiler, or CC for C compiler). GOC is used now in the Libtool patch for Go support (which has a replacement macro for AC_PROG_GO if that is not defined). Cheers, Ralf
Re: [PATCH] Ignore boilerplate logo from MSVC on stderr.
Hello Peter, * Peter Rosin wrote on Thu, Nov 18, 2010 at 11:15:21PM CET: This difference in mindset when trying to build a package is what I'm getting at, as I think people will give up more quickly when they attempt a MSVC build, as it surely can't just work... I'm sorry this is dragging on so long and being so painful for you. I would like to see necessary arguments removed and wrappers used as seamlessly as possible, but it needs to happen without degrading Autoconf maintainability and with the usual configure logic of testing for features. I just don't think that we've found the best solution here yet. As long as workarounds are needed, maybe the best way to proceed is to document them in one place, so they can easily be found? One practical issue here is that GNU manuals should not recommend non-free software, so the obvious place is not available. Thanks, Ralf
Re: PATCH RFA: Add support for Go programming language
Hello Eric, Ian,
* Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 11:06:07PM CEST:
Ralf Wildenhues writes:
+...@defmac AC_PROG_GO (@ovar{compiler-search-list})
+Find the Go compiler to use. Check whether the environment variable
+...@code{gccgo} is set; if so, then set output variable @code{GCCGO} to
its
+value.
Why name the variable GCCGO? In line with other compiler variables
would be something like GOC (for GO Compiler) or GOCC, that would also
match with GOFLAGS. Do you expect this interface to never apply to
non-GCC implementations of Go?
There is another Go compiler, which is called either 6g or 8g depending
on the target, but it works differently. It does not use a -c option to
compile, but instead uses a different program (6l or 8l) to link. Also
these tools generate .6 or .8 files rather than .o files, and the linker
gets the libraries directly from the .6/.8 files rather than from the
command line. So I wasn't sure whether it made sense to use the smae
make variable for both.
That said, I'm not wedded to GCCGO, and if y'all think it would be
better to use GOC or GOCC, I'm fine with making the change. It's true
that it would be possible to write a driver program for 6g/8g which make
them act more like gccgo, though the reverse would be harder.
Eric, do you have any input on this open question? Have you had a
chance to look at the patch? It otherwise seems low-danger to me, but
I wouldn't want to move forward on the Libtool sister patch without this
one cleared.
Just for reference, can you post the output of
make check TESTSUITEFLAGS='-k go -v -x'
with a Go compiler in $PATH?
Attached.
That looks fine to me.
Thanks,
Ralf
Re: Overriding LN_S
Here's testsuite exposure for your patch.
- AS_LN_S is undocumented at the moment. This would be a good
opportunity to document it, OTOH there is no pressing need,
testsuite coverage for undocumented APIs is not a problem.
- Your patch doesn't work: specifying LN_S as argument on the
configure command line does not override AC_PROG_LN_S nor AS_LN_S
usage. The reason for this is that _AS_LN_S_PREPARE is (necessarily)
expanded in the configure script before command-line handling takes
place:
../../autoconf/tests/base.at:733: ./configure $configure_options LN_S=false
++ ./configure LN_S=false
stderr:
stdout:
checking whether ln -s works... yes
foo
../../autoconf/tests/base.at:733: exit code was 0, expected 1
So, your patch needs more work, either in autoconf.texi (documenting
that LN_S needs to be set in the environment rather than on the
configure command line) or we need to think or some other way to
fixup the _AS_LN_S_PREPARE result after command-line parsing, or
restructure the code otherwise.
Cheers,
Ralf
Testsuite coverage for LN_S overrides.
* tests/base.at (AC_PROG_LN_S): New test.
* tests/m4sh.at (AS@t...@_ln_s): Likewise.
diff --git a/tests/base.at b/tests/base.at
index 0973fc4..b545bc4 100644
--- a/tests/base.at
+++ b/tests/base.at
@@ -708,3 +708,28 @@ libdir=${exec_prefix}/lib
]])
AT_CLEANUP
+
+
+## - ##
+## AC_PROG_LN_S ##
+## - ##
+
+AT_SETUP([AC_PROG_LN_S])
+
+AT_DATA([configure.ac],
+[[AC_INIT
+AC_PROG_LN_S
+rm -f foo link
+echo foo file
+$LN_S file link || AC_MSG_ERROR([$LN_S failed])
+grep foo link || AC_MSG_ERROR([link not created correctly])
+]])
+
+AT_CHECK_AUTOCONF
+AT_CHECK_CONFIGURE
+AT_CHECK_CONFIGURE([LN_S='cp -p'])
+rm -f foo
+AT_CHECK([grep foo link], [], [ignore])
+AT_CHECK_CONFIGURE([LN_S=false], [1], [ignore], [ignore])
+
+AT_CLEANUP
diff --git a/tests/m4sh.at b/tests/m4sh.at
index c01027f..918975a 100644
--- a/tests/m4sh.at
+++ b/tests/m4sh.at
@@ -518,6 +518,32 @@ AT_CHECK([$CONFIG_SHELL ./script])
AT_CLEANUP
+## ##
+## AS_MKDIR_P. ##
+## ##
+
+# Build nested dirs.
+AT_SETUP([AS@t...@_ln_s])
+AT_KEYWORDS([m4sh])
+
+AT_DATA_M4SH([script.as],
+[[AS_INIT
+rm -f foo link
+echo foo file
+AS_LN_S([file], [link]) || AS_EXIT([1])
+grep foo link || AS_EXIT([1])
+]])
+
+AT_CHECK_M4SH
+AT_CHECK([$CONFIG_SHELL ./script], [], [foo
+])
+AT_CHECK([env LN_S='cp -p' $CONFIG_SHELL ./script], [], [foo
+])
+rm -f foo
+AT_CHECK([grep foo link], [], [ignore])
+AT_CHECK([env LN_S='false' $CONFIG_SHELL ./script], [1])
+
+AT_CLEANUP
## ##
Re: Overriding LN_S
By the way, you can test the new tests with make check TESTSUITEFLAGS='-v -d -x -k AS_LN_S -k AC_PROG_LN_S' * Ralf Wildenhues wrote on Sat, Oct 16, 2010 at 11:30:01AM CEST: --- a/tests/m4sh.at +++ b/tests/m4sh.at @@ -518,6 +518,32 @@ AT_CHECK([$CONFIG_SHELL ./script]) AT_CLEANUP +## ## +## AS_MKDIR_P. ## +## ## Consider this typo fixed. + +# Build nested dirs. +AT_SETUP([AS@t...@_ln_s]) +AT_KEYWORDS([m4sh]) [...]
Re: Overriding LN_S
* Peter Rosin wrote on Fri, Oct 15, 2010 at 11:15:33PM CEST: Den 2010-10-15 19:51 skrev Ralf Wildenhues: With that fixed, I ran the testsuite on GNU/Linux once without LN_S set, once with export LN_S='cp -p', both successfully, but with LN_S=bla, the only failure is from the foreign.at:Libtool test, because libtoolize honors $LN_S. Wasn't that unexpectedly few failures for the last case? Right. I think a testsuite addition that ensures that LN_S is honored for both AC_PROG_LN_S and for AS_LN_S is in order; we have already regressed on this once, a few years ago. Please ping me if you want me to write one. I don't feel at home in the autoconf testsuite I'll look into it. I'll make up for it by delaying your pending Automake patch for another little while. ;-) Cheers, Ralf
Re: PATCH RFA: Add support for Go programming language
Hi Ian,
* Ian Lance Taylor wrote on Tue, Oct 12, 2010 at 09:37:40PM CEST:
This patch adds support for the Go programming language to autoconf.
The Go programming language is described at http://golang.org/ .
This is fairly basic support. It only works with gccgo, the Go frontend
to gcc. It has no special features. However, it is enough to write
AC_PROG_GO and have the GCCGO and GOFLAGS variables set for use in a
Makefile.
Please let me know what steps I should take to get this into the
mainline of autoconf. Thanks.
Thanks for the patch. I'll leave approval to Eric, and just note a
couple of nits/questions below.
Cheers,
Ralf
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -341,7 +341,7 @@ Top
* Preset Output Variables:: Output variables that are always set
* Installation Directory Variables:: Other preset output variables
-* Changed Directory Variables:: Warnings about @file{datarootdir}
+* Changed Directory Variables:: Warnings about @file{datarootdir}
Did you do the menu rebuilding automatically? If yes, how?
* Build Directories:: Supporting multiple concurrent compiles
* Automatic Remaking:: Makefile rules for configuring
@@ -8207,6 +8224,32 @@ Fortran Compiler
@end defmac
+...@node Go Compiler
+...@subsection Go Compiler Characteristics
+...@cindex Go
+
+Autoconf provides basic support for the Go programming language when
+using the @code{gccgo} compiler (there is currently no support for the
+...@code{6g} and @code{8g} compilers).
+
+...@defmac AC_PROG_GO (@ovar{compiler-search-list})
+Find the Go compiler to use. Check whether the environment variable
+...@code{gccgo} is set; if so, then set output variable @code{GCCGO} to its
+value.
Why name the variable GCCGO? In line with other compiler variables
would be something like GOC (for GO Compiler) or GOCC, that would also
match with GOFLAGS. Do you expect this interface to never apply to
non-GCC implementations of Go?
+Otherwise, if the macro is invoked without an argument, then search for
+a Go compiler named @code{gccgo}. If it is not found, then as a last
+resort set @code{GCCGO} to @code{gccgo}.
+
+This macro may be invoked with an optional first argument which, if
+specified, must be a blank-separated list of Go compilers to search for.
+
+If output variable @code{GOFLAGS} was not already set, set it to
+...@option{-g -O2}. If your package does not like this default,
+...@code{goflags} may be set before @code{AC_PROG_GO}.
+...@end defmac
+
+
@node System Services
@section System Services
--- /dev/null
+++ b/lib/autoconf/go.m4
+# AC_LANG_INT_SAVE(Go)(PROLOGUE, EXPRESSION)
+# --
+m4_define([AC_LANG_INT_SAVE(Go)],
+[AC_LANG_PROGRAM([$1
+import (
+ fmt
+ os
+)
+],
+[f, err := os.Open(conftest.val, os.O_CREATE|os.O_WRONLY, 0777)
Does Go require no space before open parentheses, or is it conventional
to not follow GCS spacing in Go?
+ if err != nil {
+ os.Exit(1)
+ }
+ if $2 0 {
+ int64 i = int64($2)
+ if i != $2 {
+ os.Exit(1)
+ }
+ if _, err := fmt.Print(f, i); err != nil {
+ os.Exit(1)
+ }
+ } else {
+ uint64 i = uint64($2)
+ if i != $2 {
+ os.Exit(1)
+ }
+ if _, err := fmt.Print(f, i); err != nil {
+ os.Exit(1)
+ }
+ }
+ if err = f.Close(); err != nil {
+ os.Exit(1)
+ }
+ os.Exit(0);
+])])
+
+# -- #
+# Looking for compilers. #
+# -- #
+
+# AC_LANG_COMPILER(Go)
+#
+AC_DEFUN([AC_LANG_COMPILER(Go)],
+[AC_REQUIRE([AC_PROG_GO])])
+
+# AC_PROG_GO
+# --
+AN_MAKEVAR([GCCGO], [AC_PROG_GO])
+AN_PROGRAM([gccgo], [AC_PROG_GO])
+AC_DEFUN([AC_PROG_GO],
+[AC_LANG_PUSH(Go)dnl
+AC_ARG_VAR([GCCGO], [Go compiler command])dnl
+AC_ARG_VAR([GOFLAGS], [Go compiler flags])dnl
+_AC_ARG_VAR_LDFLAGS()dnl
+m4_ifval([$1],
+ [AC_CHECK_TOOLS(GCCGO, [$1])],
+[AC_CHECK_TOOL(GCCGO, gccgo)
+if test -z $GCCGO; then
+ if test -n $ac_tool_prefix; then
+AC_CHECK_PROG(GCCGO, [${ac_tool_prefix}gccgo], [$ac_tool_prefix}gccgo])
+ fi
+fi
+if test -z $GCCGO; then
+ AC_CHECK_PROG(GCCGO, gccgo, gccgo, , , gccgo)
The sixth argument to AC_CHECK_PROG doesn't make sense to me. It should
name an absolute file name that would always be rejected, but 'gccgo' is
not absolute. OTOH, the fourth VALUE-IF-NOT-FOUND argument is empty,
which is probably not very helpful either. I'd prefer 'false', so
compile rules are guaranteed to fail; notwithstanding the practice to
not do so in other AC_PROG_* macros.
+fi
+])
+
+# Provide some information about the compiler.
+_AS_ECHO_LOG([checking for _AC_LANG compiler version])
+set X $ac_compile
+ac_compiler=$[2]
+_AC_DO_LIMIT([$ac_compiler --version AS_MESSAGE_LOG_FD])
+m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
tests: avoid AC_CACHE_CHECK test failure with dash.
dash immediately exits a script with status 2 when a source'd '.' file has a syntax error, and doesn't return to the sourcing script. That's fine as per Posix, I guess, so normalize the exit status in the test, and if we don't find the error message, at least ensure the script didn't configure. OK? Thanks, Ralf tests: avoid AC_CACHE_CHECK test failure with dash. * tests/base.at (AC_CACHE_CHECK): Normalize configure exit status in presence of syntax error in sourced site file. Do not error out if configure is aborted at this point. Fixes testsuite failure with dash 0.5.5.1. diff --git a/tests/base.at b/tests/base.at index cf12099..0973fc4 100644 --- a/tests/base.at +++ b/tests/base.at @@ -493,8 +493,9 @@ AT_DATA([bad.site], [[fi ]]) CONFIG_SITE=$PWD/bad.site -AT_CHECK_CONFIGURE([], [1], [ignore], [stderr]) -AT_CHECK([grep 'failed to load site script' stderr], [], [ignore]) +AT_CHECK_CONFIGURE([ || exit 1], [1], [stdout], [stderr]) +AT_CHECK([grep 'failed to load site script' stderr], [], [ignore], [ignore], +[AT_CHECK([grep 'whether true' stdout], [1])]) # However, a missing file is ignored. CONFIG_SITE=./no-such-file
AT_CHECK_PROGRESS
Hello people interested in Autotest progress,
a while ago, we already pondered a bit:
http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5408
about what I called AT_CHECK_INTERACTIVE back then, namely an AT_CHECK
variant that would print output already while the commands were running,
mostly for long-running commands.
I now tried the approach Paul suggested in above thread. With testsuite
-v, it intermingles stdout and stderr of the tested commands. It does
not pipe stderr through
grep '^ *+'
as AT_CHECK does, that would cause output to be buffered again. Some
other minor details are still wrong, too.
Testing the patch was done by replacing all AT_CHECK with the _PROGRESS
variant internally:
| --- b/lib/autotest/general.m4
| +++ a/lib/autotest/general.m4
| @@ -2013,7 +2013,7 @@ $2[]_ATEOF
| # This may cause spurious failures when the test suite is run with `-x'.
| #
| _AT_DEFINE_SETUP([AT_CHECK],
| -[_AT_CHECK(m4_expand([$1]), [$2], AS_ESCAPE(m4_dquote(m4_expand([$3]))),
| +[_AT_CHECK_PROGRESS(m4_expand([$1]), [$2],
AS_ESCAPE(m4_dquote(m4_expand([$3]))),
|AS_ESCAPE(m4_dquote(m4_expand([$4]))), [$5], [$6])])
|
| # AT_CHECK_UNQUOTED(COMMANDS, [STATUS = 0], STDOUT, STDERR,
On my test system, this change caused testsuite execution time to
increase by 2%, but no failures otherwise.
The patch below is preliminary. Before it can be applied, I either need
to find out how to add testsuite exposure for AT_CHECK_PROGRESS similar
to what above delivers. And do lots of portability testing, and maybe
try some m4 or shell optimization on code size and maybe speed.
Alternatively to a new macro, however, maybe we can even let this
approach eventually serve as the default behavior of AT_CHECK.
What do you think?
The testsuite addition uses a mutex strategy to ensure concurrency.
I think this would also be a good idea as replacement for the racy
concurrency tests we currently use for parallel Autotest; I hope to
work on this later.
Thanks,
Ralf
Autotest: new macro AT_CHECK_PROGRESS.
* doc/autoconf.texi (Writing Testsuites): Document it.
* tests/autotest.at (progress): New test.
* NEWS: Update.
* lib/autotest/general.m4 (AT_INIT)
at_fn_check_prepare_notrace, at_fn_check_prepare_trace:
Also set at_check_filter_progress.
at_fn_filter_trace_progress: New helper function.
PREPARE_TESTS: Also set at_check_filter_trace_progress.
at_fn_group_prepare: Also set at_status_file1.
(AT_CHECK_PROGRESS): New macro, copied from AT_CHECK.
(AT_DIFF_STDERR_P(stderr), AT_DIFF_STDERR_P(stderr))
(AT_DIFF_STDERR_P(ignore), AT_DIFF_STDERR_P(ignore))
(AT_DIFF_STDERR_P(experr), AT_DIFF_STDERR_P())
(AT_DIFF_STDOUT_P(stdout), AT_DIFF_STDOUT_P(stdout))
(AT_DIFF_STDOUT_P(ignore), AT_DIFF_STDOUT_P(ignore))
(AT_DIFF_STDOUT_P(expout), AT_DIFF_STDOUT_P())
(_AT_CHECK_PROGRESS): New helper macros, analogous to their
AT_CHECK counterparts.
diff --git a/NEWS b/NEWS
index 83f79c7..e3a3a23 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,9 @@ GNU Autoconf NEWS - User visible changes.
** AT_CHECK semantics with respect to the Autotest variable $at_status and
shell execution environment of the arguments are documented now.
+** New Autotest macro AT_CHECK_PROGRESS that produces output while running a
+ test, for tests that run for a long time.
+
* Major changes in Autoconf 2.67 (2010-07-21) [stable]
Released by Eric Blake, based on git versions 2.66.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 6217c02..d3a1cea 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24155,8 +24155,11 @@ be a single shell word that expands into a single file
name.
@ovar{stderr}, @ovar{run-if-fail}, @ovar{run-if-pass})
@defmacx AT_CHECK_UNQUOTED (@var{commands}, @dvar{status, 0}, @ovar{stdout}, @
@ovar{stderr}, @ovar{run-if-fail}, @ovar{run-if-pass})
+...@defmacx AT_CHECK_PROGRESS (@var{commands}, @dvar{status, 0},
@ovar{stdout}, @
+ @ovar{stderr}, @ovar{run-if-fail}, @ovar{run-if-pass})
@atindex{CHECK}
@atindex{CHECK_UNQUOTED}
+...@atindex{check_progress}
@vrindex at_status
Execute a test by performing given shell @var{commands} in a subshell.
@var{commands} is output as-is, so shell expansions are honored. These
@@ -24194,7 +24197,10 @@ escaping (@samp{\}) on comparison text given in the
@var{stdout} and
@var{stderr} arguments; if the text includes a trailing newline, this
would be the same as if it were specified via an unquoted
here-document. (However, there is no difference in the interpretation
-of @var{commands}).
+of @var{commands}). The difference between @code{AT_CHECK} and
+...@code{at_check_progress} is that the latter tries to produce verbose
+output already while @var{commands} are still running, at the cost of
+some extra Autotest artefacts found in the verbose output.
@table @samp
@item ignore
diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index 344c7e9..f6ab230 100644
---
Re: Documentation correction
Josh replied off-list to my mail on the autoconf list, I'm pushing this
patch in his name and adding him to THANKS.
The (tiny change) annotation denotes that no copyright papers have been
exchanged.
Cheers,
Ralf
2010-09-24 Joshua G. Hale jgh...@... (tiny change)
docs: fix typo in AC_CONFIG_FILES example code.
* doc/autoconf.texi (Configuration Actions): Fix typo.
* THANKS: Update.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 66d8a21..0640320 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -2223,7 +2223,7 @@ Configuration Actions
@sa...@var{output}:@var{inputs}}. The file @var{output} is instantiated
from its templates, @var{inputs} (defaulting to @sa...@var{output}.in}).
-...@samp{ac_config_files([Makefile:boiler/top.mk:boiler/bot.mk)]},
+...@samp{ac_config_files([Makefile:boiler/top.mk:boiler/bot.mk])},
for example, asks for
the creation of the file @file{Makefile} that contains the expansion of the
output variables in the concatenation of @file{boiler/top.mk} and
Re: [PATCH 1/2] AC_REPLACE_FUNCS: restore shell loop for non-literal
Hi Eric, * Eric Blake wrote on Wed, Sep 22, 2010 at 01:14:09AM CEST: * lib/autoconf/functions.m4 (AC_REPLACE_FUNCS): Handle non-literals, which was lost in 2010-02-26 optimization. * tests/semantics.at (AC_REPLACE_FUNCS): Enhance test. * NEWS: Document the fix. * THANKS: Update. Reported by Wiseman Jun. Maybe not as obvious, but the enhancements to the testsuite show that when you pass non-literal lists, you are also responsible for manually calling AH_TEMPLATE for each function, as well as calling AC_LIBSOURCES for each function replacement file. Basically, this patch restores 2.65 behavior. This patch breaks automake/tests/libobj5.test. Cheers, Ralf
[PATCH] Add autom4te traces for likely future Automake macros.
* lib/autom4te.in (Automake-preselections): Trace AM_MAKEFILE_INCLUDE, AM_NLS, AM_POT_TOOLS, AM_PATH_GUILE, AM_PROG_MOC, AM_XGETTEXT_OPTION, _AM_MAKEFILE_INCLUDE. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de --- * Ralf Wildenhues wrote on Sat, Sep 18, 2010 at 07:23:54AM CEST: I've considered adding a few names to lib/autom4te.in speculatively, since Automake will be needing more of those. I'm not sure if that is sensible before we have code, but it sure could help not having to require unreleased Autoconf; as of now, I'm not aware of these new macro branches needing other support in Autoconf explicitly. A patch to this end would be this (with type AM_PROG_MOC fixed). Cheers, Ralf ChangeLog |7 +++ lib/autom4te.in |7 +++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5c80f7c..4f37265 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-09-19 Ralf Wildenhues ralf.wildenh...@gmx.de + + Add autom4te traces for likely future Automake macros. + * lib/autom4te.in (Automake-preselections): Trace + AM_MAKEFILE_INCLUDE, AM_NLS, AM_POT_TOOLS, AM_PATH_GUILE, + AM_PROG_MOC, AM_XGETTEXT_OPTION, _AM_MAKEFILE_INCLUDE. + 2010-09-16 Ralf Wildenhues ralf.wildenh...@gmx.de Add autom4te trace for AM_PROG_AR. diff --git a/lib/autom4te.in b/lib/autom4te.in index 6563e2e..434210e 100644 --- a/lib/autom4te.in +++ b/lib/autom4te.in @@ -57,13 +57,20 @@ args: --preselect AM_ENABLE_MULTILIB args: --preselect AM_GNU_GETTEXT args: --preselect AM_GNU_GETTEXT_INTL_SUBDIR args: --preselect AM_INIT_AUTOMAKE +args: --preselect AM_MAKEFILE_INCLUDE args: --preselect AM_MAINTAINER_MODE +args: --preselect AM_NLS +args: --preselect AM_POT_TOOLS +args: --preselect AM_PATH_GUILE args: --preselect AM_PROG_AR args: --preselect AM_PROG_CC_C_O args: --preselect AM_PROG_CXX_C_O args: --preselect AM_PROG_F77_C_O args: --preselect AM_PROG_FC_C_O +args: --preselect AM_PROG_MOC args: --preselect AM_SILENT_RULES +args: --preselect AM_XGETTEXT_OPTION +args: --preselect _AM_MAKEFILE_INCLUDE args: --preselect _AM_SUBST_NOTMAKE args: --preselect _AM_COND_IF args: --preselect _AM_COND_ELSE -- 1.7.3.rc1
remaining patches (was: [PATCH] build: support autobuild)
* Eric Blake wrote on Sat, Sep 18, 2010 at 01:05:50AM CEST: Any other last-minute patches to include before I start the release process? Right now, it looks like I will have things out the door on Monday. All stuff that I have is either not ready for prime time yet (sorry Peter) or can wait. I suppose I'll try to fix some of the testsuite failures in the posted logs, but so far none look like deal-breakers, and I'll let you deal with any resulting patches. I've considered adding a few names to lib/autom4te.in speculatively, since Automake will be needing more of those. I'm not sure if that is sensible before we have code, but it sure could help not having to require unreleased Autoconf; as of now, I'm not aware of these new macro branches needing other support in Autoconf explicitly. Names I'm currently thinking of: AM_POT_TOOLS AM_XGETTEXT_OPTION AM_NLSall three for the pot-primary branch AM_MAKEFILE_INCLUDE for some unfinished include feature _AM_MAKEFILE_INCLUDE alternatively, an internal helper macro AM_PATH_GUILE for addition of Guile support AM_PROG_MOV for the QT patches What do you think? Just add them, and garbage-collect later in case that was overly optimistic? Thanks, Ralf
Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.
[ adding autoconf-patches ] * Peter Rosin wrote on Thu, Sep 16, 2010 at 10:50:05AM CEST: --- a/automake.in +++ b/automake.in @@ -5242,6 +5262,7 @@ sub scan_autoconf_traces ($) AM_GNU_GETTEXT_INTL_SUBDIR = 0, AM_INIT_AUTOMAKE = 0, AM_MAINTAINER_MODE = 0, + AM_PROG_AR = 0, AM_PROG_CC_C_O = 0, AM_SILENT_RULES = 0, _AM_SUBST_NOTMAKE = 1, This requires updating of Autoconf. I'm checking the following in there. More generally, it either also requires that we bump Automake's version requirement on Autoconf, or we make the autom4te preselections test in Autoconf less strict, so that it won't fail with Automake which has the above. Or move the test to the Automake test suite. I'm a bit leery of bumping the AC_PREREQ in Automake of this, but in this case, msvc support will likely still need other things in Autoconf as well anyway ... haven't forgotten them, Peter, but I just didn't have the time yet to think enough. Cheers, Ralf Add autom4te trace for AM_PROG_AR. * lib/autom4te.in (Automake-preselections): Trace AM_PROG_AR. diff --git a/lib/autom4te.in b/lib/autom4te.in index 2bc4f8d..6563e2e 100644 --- a/lib/autom4te.in +++ b/lib/autom4te.in @@ -58,6 +58,7 @@ args: --preselect AM_GNU_GETTEXT args: --preselect AM_GNU_GETTEXT_INTL_SUBDIR args: --preselect AM_INIT_AUTOMAKE args: --preselect AM_MAINTAINER_MODE +args: --preselect AM_PROG_AR args: --preselect AM_PROG_CC_C_O args: --preselect AM_PROG_CXX_C_O args: --preselect AM_PROG_F77_C_O
Re: [PATCH] Add new 'AM_PROG_AR' macro, triggering the 'ar-lib' script.
* Eric Blake wrote on Thu, Sep 16, 2010 at 08:00:54PM CEST: On 09/16/2010 11:56 AM, Ralf Wildenhues wrote: More generally, it either also requires that we bump Automake's version requirement on Autoconf, or we make the autom4te preselections test in Autoconf less strict, so that it won't fail with Automake which has the above. Or move the test to the Automake test suite. Didn't we already relax the test at one point to SKIP if the version of automake run by the test differs from the version of automake used by the developer building autoconf? In particular: http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=87ccb0b79 Indeed. That means I must go back to a couple of test systems and find out why I got testsuite failures there ... oh wait, I did bootstrap Autoconf with that Automake version. Hmpf. Thanks, Ralf
autobuild logs for Autoconf
Hi Eric, I sent a bunch of logs to http://autobuild.josefsson.org/autoconf/ for git Autoconf plus the two diffs below. The second is for Solaris 2.6 whose compiler generates core files for one particular configure test (don't remember which) which causes lots of spurious test failures. In my testing, I removed GNU tools from PATH as much as possible. Cheers, Ralf diff --git a/configure.ac b/configure.ac index 5718a24..4102404 100644 --- a/configure.ac +++ b/configure.ac @@ -31,6 +31,8 @@ AC_CONFIG_AUX_DIR([build-aux]) AM_INIT_AUTOMAKE([1.11 dist-bzip2 dist-xz readme-alpha no-texinfo.tex std-options]) +m4_ifdef([AB_INIT], [AB_INIT]) + # We use `/bin/sh -n script' to check that there are no syntax errors # in the scripts. Although incredible, there are /bin/sh that go into # endless loops with `-n', e.g., SunOS's: diff --git a/tests/statesave.m4 b/tests/statesave.m4 index 06d1361..2aa6d65 100644 --- a/tests/statesave.m4 +++ b/tests/statesave.m4 @@ -31,7 +31,7 @@ # directory, while avoiding yet another fork. m4_defun([AC_STATE_SAVE], [(set) 21 | sort state-env.$1 -ls | sed '/^at-/d;/^state-/d;/^config\./d +ls | sed '/^at-/d;/^state-/d;/^config\./d;/^core$/d h :b $b
Re: docs: document zsh specialty with empty here-documents.
Hi Gary and Eric,
* Eric Blake wrote on Mon, Sep 13, 2010 at 04:40:06PM CEST:
On 09/12/2010 09:55 PM, Gary V. Vaughan wrote:
On 12 Sep 2010, at 23:41, Ralf Wildenhues wrote:
docs: document zsh specialty with empty here-documents.
* doc/autoconf.texi (Here-Documents): zsh 4.3.10 adds a newline
to empty here-docs.
[...]
Two colons in a sentence seems odd to me, and the English doesn't parse
well either. How about:
Empty here-documents are not portable either; with the following code,
@command{zsh} 4.3.10 creates a file with a single newline, whereas other
shells create an empty file:
Also, is it really just that one micro release of zsh that has this
problem? Or do you mean since 4.3.10 or maybe before 4.3.10 or
even at least 4.3.10?
I like at least 4.3.10. Okay with Gary's proposed wording changes.
Thanks for the reviews. I'm pushing as below, hoping that's what you
intended.
I've reported a bug on http://news.gmane.org/gmane.comp.shells.zsh.devel
but it hasn't shown up there yet.
Cheers,
Ralf
2010-09-13 Ralf Wildenhues ralf.wildenh...@gmx.de
Gary V. Vaughan g...@gnu.org
docs: document zsh specialty with empty here-documents.
* doc/autoconf.texi (Here-Documents): zsh 4.3.10 adds a newline
to empty here-docs.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index f11f1dd..71eefa4 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -14897,6 +14897,15 @@ Here-Documents
@samp{ksh93g} (1998-04-30) but as of 2006 many operating systems were
still shipping older versions with the bug.
+Empty here-documents are not portable either; with the following code,
+...@command{zsh} up to at least version 4.3.10 creates a file with a single
+newline, whereas other shells create an empty file:
+
+...@example
+cat file EOF
+EOF
+...@end example
+
Many shells (including the Bourne shell) implement here-documents
inefficiently. In particular, some shells can be extremely inefficient when
a single statement contains many here-documents. For instance if your
Re: [PATCH 2/2] doc: index entries for non-environment, non-output variables.
Hi Eric, and thanks for the reviews,
I've taken the uncontroversial part of 1/2 and pushed that now.
* Eric Blake wrote on Tue, Sep 07, 2010 at 04:29:51PM CEST:
On 09/06/2010 12:06 AM, Ralf Wildenhues wrote:
@@ -4316,6 +4316,7 @@ Generic Programs
@ovar{action-if-not-found}, @dvar{path, $PATH})
@acindex{PATH_PROGS_FEATURE_CHECK}
@caindex pa...@var{variable}
+...@evindex ac_pa...@var{variable}
This macro was introduced in Autoconf 2.62. If @var{variable} is not
empty, then set the cache variable @code{ac_cv_pa...@var{variable}} to
Is this right?
This section talks about:
ac_cv_path_VARIABLE
ac_path_VARIABLE_found
But not ac_path_VARIABLE.
Both are mentioned:
For each program
found, execute @var{feature-test} with @code{ac_pa...@var{variable}}
set to the absolute name of the candidate program. [...]
[...] to accept the
current setting and bypass all futher checks, @var{feature-test} can
execute @code{ac_pa...@var{variable}_found=:}.
So I guess both of these could be indexed.
* Eric Blake wrote on Tue, Sep 07, 2010 at 04:35:09PM CEST:
On 09/06/2010 12:07 AM, Ralf Wildenhues wrote:
* doc/autoconf.texi: Merge variable index `vr' into concept
index using syncodeindex.
* doc/autoconf.texi (Configuration Actions, Generic Programs)
(Generic Functions, Initialization Macros, Writing Testsuites):
Add index entries for documented shell variables used during
in configure and testsuite scripts. Fix entry for `tmp'.
@table @code
@item srcdir
+...@vrindex srcdir
Why @vrindex instead of @ovindex? We already document:
@c Define an output variable index.
@defcodeindex ov
for all variables that are set during configure/autotest for use by
the remainder of the script.
[...]
Oh, I see - you're trying to make a distinction between @ovindex and
@vrindex. Can we document that distinction both in the commit
message and in the comments at the top of autoconf.texi that
describe all the various indices?
Sure. Here's a redo of the remainder of 1/2 and fixed 2/2, with
comments for the various indices updated. OK?
Thanks,
Ralf
doc: index entries for non-environment, non-output variables.
* doc/autoconf.texi: Clarify the meaning of the various variable
indices. Merge variable index `vr' into concept index using
syncodeindex.
(Configuration Actions, Generic Programs, Generic Functions)
(Writing Testsuites): Add index entries for documented shell
variables used during in configure and testsuite scripts.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index e068ff7..22fd614 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -46,14 +46,18 @@
@c with texi2dvi. But then you wake up an old problem: we use macros
@c in @defmac etc. where TeX does perform the expansion, but not makeinfo.
-...@c Define an environment variable index.
+...@c Define an environment variable index, for variables users may set
+...@c in their environment or on the configure command line.
@defcodeindex ev
-...@c Define an output variable index.
+...@c Define an output variable index, for commonly AC_SUBST'ed variables.
@defcodeindex ov
-...@c Define a CPP variable index.
-...@defcodeindex cv
-...@c Define a cache variable index.
+...@c Define a cache variable index, for variables matching *_cv_*.
@defcodeindex CA
+...@c Other shell variables not fitting the above categories should be
+...@c listed in the predefined vrindex, which we merge in the concept index.
+...@syncodeindex vr cp
+...@c Define a CPP preprocessor macro index, for #define'd strings.
+...@defcodeindex cv
@c Define an Autoconf macro index that @defmac doesn't write to.
@defcodeindex AC
@c Define an Autotest macro index that @defmac doesn't write to.
@@ -2250,25 +2254,30 @@ Configuration Actions
@table @code
@item srcdir
+...@vrindex srcdir
The name of the top source directory, assuming that the working
directory is the top build directory. This
is what the @command{configure} option @option{--srcdir} sets.
@item ac_top_srcdir
+...@vrindex ac_top_srcdir
The name of the top source directory, assuming that the working
directory is the current build directory.
@item ac_top_build_prefix
+...@vrindex ac_top_build_prefix
The name of the top build directory, assuming that the working
directory is the current build directory.
It can be empty, or else ends with a slash, so that you may concatenate
it.
@item ac_srcdir
+...@vrindex ac_srcdir
The name of the corresponding source directory, assuming that the
working directory is the current build directory.
@item tmp
+...@vrindex tmp
The name of a temporary directory within the build tree, which you
can use if you need to create additional temporary files. The
directory is cleaned up when @command{config.status} is done or
@@ -4320,6 +4329,8 @@ Generic Programs
@ovar{action-if-not-found}, @dvar{path, $PATH})
@acindex{PATH_PROGS_FEATURE_CHECK}
@caindex pa...@var{variable}
+...@vrindex
doc: minor updates.
OK? This makes all @uref's look nice in PDF output.
Thanks,
Ralf
doc: minor updates.
* doc/autoconf.texi (Generic Compiler Characteristics): Use
second argument of @uref consistently, for nicer OpenMP link.
(Polymorphic Variables): Restore font-lock.
(Debugging): Add item for bashdb.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1b22c26..d3774c0 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -7051,7 +7051,7 @@ Generic Compiler Characteristics
@ovindex OPENMP_CXXFLAGS
@ovindex OPENMP_FFLAGS
@ovindex OPENMP_FCFLAGS
-OpenMP (@url{http://@/www.openmp.org/}) specifies extensions of C, C++,
+...@uref{http://@/www.openmp.org/, OpenMP} specifies extensions of C, C++,
and Fortran that simplify optimization of shared memory parallelism,
which is a common problem on multicore CPUs.
@@ -13467,6 +13467,7 @@ Polymorphic Variables
AC_DEFUN([MY_ACTION],
[AS_LITERAL_IF([$1],
[echo $$1],
+...@c $$
[AS_VAR_COPY([var], [$1])
echo $var],
[eval 'echo $'$1\])])
@@ -25217,6 +25218,10 @@ Debugging
@var{log-file}.
@item
+Alternatively, you might use a shell with debugging capabilities like
+...@uref{http://bashdb.sourceforge.net/, bashdb}.
+
+...@item
When @command{configure} tests produce invalid results for your system,
it may be necessary to override them:
docs: document zsh special array $options.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10643
Quoting zshall(1):
THE ZSH/PARAMETER MODULE
The zsh/parameter module gives access to some of the internal hash
tables used by the shell by defining some special parameters.
options
The keys for this associative array are the names of the options
that can be set and unset using the setopt and unsetopt
builtins. The value of each key is either the string on if the
option is currently set, or the string off if the option is
unset. Setting a key to one of these strings is like setting or
unsetting the option, respectively. Unsetting a key in this
array is like setting it to the value off.
This lives even after 'emulate sh'. OK to commit?
Thanks,
Ralf
docs: document zsh special array $options.
* doc/autoconf.texi (Special Shell Variables): Add entry for
`options'.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index d3774c0..e8d65cb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -16432,6 +16432,11 @@ Special Shell Variables
and forget to set @env{NULLCMD},
your script might be suspended waiting for data on its standard input.
+...@item options
+...@evindex options
+For @command{zsh} 4.3.10, @env{options} is treated as an associative
+array even after @code{emulate sh}, so it should not be used.
+
@item PATH_SEPARATOR
@evindex PATH_SEPARATOR
On DJGPP systems, the @env{PATH_SEPARATOR} environment
docs: document zsh specialty with empty here-documents.
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10647
OK? The AT_DATA documentation already specifies that $2 should end in a
newlines, so that part didn't need an update.
Thanks,
Ralf
docs: document zsh specialty with empty here-documents.
* doc/autoconf.texi (Here-Documents): zsh 4.3.10 adds a newline
to empty here-docs.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index e8d65cb..344aefa 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -14897,6 +14897,15 @@ Here-Documents
@samp{ksh93g} (1998-04-30) but as of 2006 many operating systems were
still shipping older versions with the bug.
+Empty here-documents are not portable either: @command{zsh} 4.3.10 creates
+a file with a single newline upon, whereas other shells create an empty
+file, upon:
+
+...@example
+cat file EOF
+EOF
+...@end example
+
Many shells (including the Bourne shell) implement here-documents
inefficiently. In particular, some shells can be extremely inefficient when
a single statement contains many here-documents. For instance if your
Re: [PATCH] docs: mention traditional awk limitation
* Eric Blake wrote on Tue, Sep 07, 2010 at 11:53:10PM CEST: * doc/autoconf.texi (Limitations of Usual Tools) awk: Mention that traditional awk lacks ENVIRON. Reported by Ralf Wildenhues. Does this patch look okay? Yep, thanks! The Solaris awk(1) page is really succinct, the only documented built-in variables are FILENAME, FS, NF, NR, OFMT, OFS, ORS, and RS. Pointing to the gawk.info node Language History is probably a good idea, too, its sub-nodes have lots more details. Cheers, Ralf
two small doc patches for doc index
I've been looking a bit into the texinfo indexing stuff, see http://thread.gmane.org/gmane.comp.tex.texinfo.bugs/5088 for an interesting thread that also highlights some problems with autoconf's massive use of indices. Anyway, let's start off with two small patches that fix a few very minor glitches and make things a bit more consistent. 1) @cindex entries do not automatically get @code, so they may need annotation. Also, the m4_ and AS_ index could describe the naming a bit better. 2) index variables which are used during configure or during config.status. Put them in vrindex, but merge that index into the general concept index, in order to not increase the number of indices further. Cheers, Ralf
[PATCH 1/2] doc: minor indexing update.
* doc/autoconf.texi (Generic Programs): Add variable index for
ac_path_VARIABLE.
(Shell Substitutions, Site Defaults): Fix markup for indexed
entried, using @code and @file as appropriate.
(M4 Macro Index): Clarify which of the indexed macros have m4_
and which have AS_ prefix.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
ChangeLog | 10 ++
doc/autoconf.texi | 39 +--
2 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 0c3e5d4..a7ff0a5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2010-09-05 Ralf Wildenhues ralf.wildenh...@gmx.de
+
+ doc: minor indexing update.
+ * doc/autoconf.texi (Generic Programs): Add variable index for
+ ac_path_VARIABLE.
+ (Shell Substitutions, Site Defaults): Fix markup for indexed
+ entried, using @code and @file as appropriate.
+ (M4 Macro Index): Clarify which of the indexed macros have m4_
+ and which have AS_ prefix.
+
2010-08-30 Eric Blake ebl...@redhat.com
tests: avoid trashing /
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 923fff6..0957c91 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4316,6 +4316,7 @@ Generic Programs
@ovar{action-if-not-found}, @dvar{path, $PATH})
@acindex{PATH_PROGS_FEATURE_CHECK}
@caindex pa...@var{variable}
+...@evindex ac_pa...@var{variable}
This macro was introduced in Autoconf 2.62. If @var{variable} is not
empty, then set the cache variable @code{ac_cv_pa...@var{variable}} to
its value. Otherwise, check for each program in the blank-separated
@@ -15375,7 +15376,7 @@ Shell Substitutions
@table @code
@item $@@
-...@cindex @samp{$@@}
+...@cindex @code{$@@}
One of the most famous shell-portability issues is related to
@samp{$@@}. When there are no positional arguments, Posix says
that @samp{$@@} is supposed to be equivalent to nothing, but the
@@ -15452,9 +15453,9 @@ Shell Substitutions
@item $...@{@var{var}:-...@var{value}@}
@c Info cannot handle `:' in index entries.
@ifnotinfo
-...@cindex $...@{@var{var}:-...@var{value}@}
+...@cindex @cod...@{@var{var}:-...@var{value}@}}
@end ifnotinfo
-...@cindex $...@{@var{va...@var{value}@}
+...@cindex @cod...@{@var{va...@var{value}@}}
Old BSD shells, including the Ultrix @code{sh}, don't accept the
colon for any shell substitution, and complain and die.
Similarly for $...@{@var{var}:=...@var{value}@},
$...@{@var{var}:?...@var{value}@}, etc.
@@ -15463,7 +15464,7 @@ Shell Substitutions
use null variable substitution patterns in configure scripts.
@item $...@{@var{va...@var{value}@}
-...@cindex $...@{@var{va...@var{value}@}
+...@cindex @cod...@{@var{va...@var{value}@}}
When using @sam...@{@var{va...@var{value}@}} or
@sam...@{@var{va...@var{value}@}} for providing alternate substitutions,
@var{value} must either be a single shell word, quoted, or in the
@@ -15537,7 +15538,7 @@ Shell Substitutions
@end example
@item $...@{@var{va...@var{value}@}
-...@cindex $...@{@var{va...@var{value}@}
+...@cindex @cod...@{@var{va...@var{value}@}}
When using @sam...@{@var{va...@var{value}@}} to assign a default value
to @var{var}, remember that even though the assignment to @var{var} does
not undergo file name expansion, the result of the variable expansion
@@ -15627,7 +15628,7 @@ Shell Substitutions
@end example
@item $...@{@var{va...@var{value}@}
-...@cindex $...@{@var{va...@var{literal}@}
+...@cindex @cod...@{@var{va...@var{literal}@}}
Solaris @command{/bin/sh} has a frightening bug in its handling of
literal assignments. Imagine you need set a variable to a string containing
@sa...@}}. This @sa...@}} character confuses Solaris @command{/bin/sh}
@@ -15654,7 +15655,7 @@ Shell Substitutions
problematic string.
@item $...@{@var{va...@var{expanded-value}@}
-...@cindex $...@{@var{va...@var{expanded-value}@}
+...@cindex @cod...@{@var{va...@var{expanded-value}@}}
On Ultrix,
running
@@ -15722,11 +15723,11 @@ Shell Substitutions
@itemx $...@{@var{var...@var{word}@}
@itemx $...@{@var{va...@var{word}@}
@itemx $...@{@var{var...@var{word}@}
-...@cindex $...@{#@var{v...@}
-...@cindex $...@{@var{va...@var{word}@}
-...@cindex $...@{@var{var...@var{word}@}
-...@cindex $...@{@var{va...@var{word}@}
-...@cindex $...@{@var{var...@var{word}@}
+...@cindex @cod...@{#@var{v...@}}
+...@cindex @cod...@{@var{va...@var{word}@}}
+...@cindex @cod...@{@var{var...@var{word}@}}
+...@cindex @cod...@{@var{va...@var{word}@}}
+...@cindex @cod...@{@var{var...@var{word}@}}
Posix requires support for these usages, but they do not work with many
traditional shells, e.g., Solaris 10 @command{/bin/sh}.
@@ -15737,7 +15738,7 @@ Shell Substitutions
@item `...@var{commands}`
-...@cindex `...@var{commands}`
+...@cindex @cod...@var{commands}`}
@cindex Command Substitution
Posix requires shells to trim all trailing newlines from command
output before substituting it, so assignments like
@@ -15794,7 +15795,7
[PATCH 2/2] doc: index entries for non-environment, non-output variables.
* doc/autoconf.texi: Merge variable index `vr' into concept
index using syncodeindex.
* doc/autoconf.texi (Configuration Actions, Generic Programs)
(Generic Functions, Initialization Macros, Writing Testsuites):
Add index entries for documented shell variables used during
in configure and testsuite scripts. Fix entry for `tmp'.
Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de
---
ChangeLog |8
doc/autoconf.texi | 18 --
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a7ff0a5..e36b261 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2010-09-05 Ralf Wildenhues ralf.wildenh...@gmx.de
+ doc: index entries for non-environment, non-output variables.
+ * doc/autoconf.texi: Merge variable index `vr' into concept
+ index using syncodeindex.
+ * doc/autoconf.texi (Configuration Actions, Generic Programs)
+ (Generic Functions, Initialization Macros, Writing Testsuites):
+ Add index entries for documented shell variables used during
+ in configure and testsuite scripts. Fix entry for `tmp'.
+
doc: minor indexing update.
* doc/autoconf.texi (Generic Programs): Add variable index for
ac_path_VARIABLE.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 0957c91..1849387 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -188,6 +188,9 @@
@c @c Put the programs and functions into their own index.
@c @syncodeindex fu pr
+...@c Merge variable index into concept index.
+...@syncodeindex vr cp
+
@comment %**end of header
@comment
@@ -2249,25 +2252,30 @@ Configuration Actions
@table @code
@item srcdir
+...@vrindex srcdir
The name of the top source directory, assuming that the working
directory is the top build directory. This
is what the @command{configure} option @option{--srcdir} sets.
@item ac_top_srcdir
+...@vrindex ac_top_srcdir
The name of the top source directory, assuming that the working
directory is the current build directory.
@item ac_top_build_prefix
+...@vrindex ac_top_build_prefix
The name of the top build directory, assuming that the working
directory is the current build directory.
It can be empty, or else ends with a slash, so that you may concatenate
it.
@item ac_srcdir
+...@vrindex ac_srcdir
The name of the corresponding source directory, assuming that the
working directory is the current build directory.
@item tmp
+...@vrindex tmp
The name of a temporary directory within the build tree, which you
can use if you need to create additional temporary files. The
directory is cleaned up when @command{config.status} is done or
@@ -4316,7 +4324,7 @@ Generic Programs
@ovar{action-if-not-found}, @dvar{path, $PATH})
@acindex{PATH_PROGS_FEATURE_CHECK}
@caindex pa...@var{variable}
-...@evindex ac_pa...@var{variable}
+...@vrindex ac_pa...@var{variable}
This macro was introduced in Autoconf 2.62. If @var{variable} is not
empty, then set the cache variable @code{ac_cv_pa...@var{variable}} to
its value. Otherwise, check for each program in the blank-separated
@@ -5544,6 +5552,7 @@ Generic Functions
Specify that @sa...@var{function}.c} must be included in the executables
to replace a missing or broken implementation of @var{function}.
+...@vrindex ac_objext
Technically, it adds @sa...@var{function}.$ac_objext} to the output
variable @code{LIBOBJS} if it is not already in, and calls
@code{AC_LIBSOURCE} for @sa...@var{function}.c}. You should not
@@ -13706,7 +13715,7 @@ Initialization Macros
@defmac AS_TMPDIR (@var{prefix}, @dvar{dir, $...@{tmpdir:=/t...@}})
@asindex{TMPDIR}
@evindex TMPDIR
-...@ovindex tmp
+...@vrindex tmp
Create, as safely as possible, a temporary sub-directory within
@var{dir} with a name starting with @var{prefix}. @var{prefix} should
be 2-4 characters, to make it slightly easier to identify the owner of
@@ -23934,6 +23943,7 @@ Writing Testsuites
@defmac AT_ARG_OPTION (@var{options}, @var{help-text}, @
@ovar{action-if-given}, @ovar{action-if-not-given})
@atindex{ARG_OPTION}
+...@vrindex at_a...@var{option}
Accept options from the space-separated list @var{options}, a list that
has leading dashes removed from the options. Long options will be
prefixed with @samp{--}, single-character options with @samp{-}. The
@@ -23947,6 +23957,8 @@ Writing Testsuites
option, or passes @option{--...@var{option}}, then the variable will be
set to @samp{false}.
+...@vrindex at_optarg
+...@vrindex at_opta...@var{option}
@var{action-if-given} is run each time the option is encountered; here,
the variable @code{at_optarg} will be set to @samp{:} or @samp{false} as
appropriate. @code{at_optarg} is actually just a copy of
@@ -23965,6 +23977,7 @@ Writing Testsuites
@defmac AT_ARG_OPTION_ARG (@var{options}, @var{help-text}, @
@ovar{action-if-given}, @ovar{action-if-not-given})
@atindex{ARG_OPTION_ARG
Re: document $at_status for use in RUN-IF-{PASS,FAIL} of AT_CHECK
* Eric Blake wrote on Mon, Aug 23, 2010 at 04:35:18PM CEST:
On 08/20/2010 10:51 PM, Ralf Wildenhues wrote:
Would you accept a patch to document $at_status being usable in the
RUN-IF-FAIL and RUN-IF-PASS arguments of AT_CHECK (including coverage
of course)?
Sounds good to me, unless you like my alternate idea:
[...]
However, while those alternate heuristics will allow us to avoid
exposing $at_status, it seems like a lot of complexity in the
autotest/general.m4 file, compared to just documenting a fixed name
that is available without any extra user effort.
I agree.
Proposed patch (relies on the two indexing patches for the @vrindex to
appear anywhere).
Thanks,
Ralf
autotest: document and test at_status semantics.
* doc/autoconf.texi (Writing Testsuites): Document $at_status.
* tests/autotest.at (at_status): New test.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index bfe55e6..a7f9068 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,8 @@ GNU Autoconf NEWS - User visible changes.
** Autotest testsuites should not contain long text lines any more, and be
portable even when very many test groups are used.
+** The Autotest variable $at_status is documented now.
+
* Major changes in Autoconf 2.67 (2010-07-21) [stable]
Released by Eric Blake, based on git versions 2.66.*.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 1849387..caa6309 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24141,6 +24141,7 @@ Writing Testsuites
@ovar{stderr}, @ovar{run-if-fail}, @ovar{run-if-pass})
@atindex{CHECK}
@atindex{CHECK_UNQUOTED}
+...@vrindex at_status
Execute a test by performing given shell @var{commands}. @var{commands}
is output as-is, so shell expansions are honored. These commands
should normally exit with @var{status}, while producing expected
@@ -24149,7 +24150,9 @@ Writing Testsuites
@var{commands} exit with unexpected status 99, then the test group is
immediately failed. Otherwise, if this test
fails, run shell commands @var{run-if-fail} or, if this test passes, run shell
-commands @var{run-if-pass}.
+commands @var{run-if-pass}. At the beginning of @var{run-if-fail} and
+...@var{run-if-pass}, the status of @var{commands} is available in the
+...@code{at_status} shell variable.
This macro must be invoked in between @code{AT_SETUP} and @code{AT_CLEANUP}.
diff --git a/tests/autotest.at b/tests/autotest.at
index fc636e9..725da38 100644
--- a/tests/autotest.at
+++ b/tests/autotest.at
@@ -405,6 +405,33 @@ AT_CHECK_AT_TEST([errexit],
AT_CHECK([grep inhibited subsequent stderr], [], [ignore])],
[--errexit])
+
+AT_CHECK_AT_TEST([at_status],
+ [AT_CHECK([exit $mystatus], [$expected], [], [],
+ [AT_CHECK([echo run-if-fail: $at_status], [], [ignore])],
+ [AT_CHECK([echo run-if-pass: $at_status], [], [ignore])])
+ AT_CLEANUP
+ AT_SETUP([test with nested checks])
+ AT_CHECK([exit $mystatus], [$expected], [], [],
+ [AT_CHECK([exit $mystatus], [$expected], [], [],
+ [AT_CHECK([echo inner run-if-fail: $at_status], [],
+ [ignore])])])],
+ [], [], [stdout], [],
+[], [
+AT_CHECK([grep 'inner run-if-fail: 42' stdout], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite -x -v 1 mystatus=0 expected=0], [],
[stdout])
+AT_CHECK([grep 'run-if-pass: 0' stdout], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite -x -v 1 mystatus=42 expected=0], [],
[stdout])
+AT_CHECK([grep 'run-if-fail: 42' stdout], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite -x -v 1 mystatus=0 expected=42], [],
[stdout])
+AT_CHECK([grep 'run-if-fail: 0' stdout], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite -x -v 1 mystatus=42 expected=42], [],
[stdout])
+AT_CHECK([grep 'run-if-pass: 42' stdout], [], [ignore])
+],
+[-v mystatus=42 expected=1
+])
+
+
AT_CHECK_AT_TEST([unquoted output],
[m4_define([backtick], [`])
a=a
Document and test AT_CHECK args shell execution environment. (was: document $at_status for use in RUN-IF-{PASS,FAIL} of AT_CHECK)
* Ralf Wildenhues wrote on Mon, Sep 06, 2010 at 08:08:55AM CEST:
autotest: document and test at_status semantics.
And while we are here, we could also document the execution environment
of the first, fifth, and sixth argument for AT_CHECK. WDYT?
I think some of the tests may be relying on this implicitly already.
Haven't checked though.
Thanks,
Ralf
Document and test AT_CHECK args shell execution environment.
* doc/autoconf.texi (Writing Testsuites): Document that COMMANDS
is run in a subshell, but RUN-IF-FAIL and RUN-IF-PASS are not.
* tests/autotest.at (AT@t...@_check execution environment): New
test.
* NEWS: Update.
diff --git a/NEWS b/NEWS
index a7f9068..43e3621 100644
--- a/NEWS
+++ b/NEWS
@@ -25,7 +25,8 @@ GNU Autoconf NEWS - User visible changes.
** Autotest testsuites should not contain long text lines any more, and be
portable even when very many test groups are used.
-** The Autotest variable $at_status is documented now.
+** AT_CHECK semantics with respect to the Autotest variable $at_status and
+ shell execution environment of the arguments are documented now.
* Major changes in Autoconf 2.67 (2010-07-21) [stable]
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index caa6309..023135f 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24142,17 +24142,17 @@ Writing Testsuites
@atindex{CHECK}
@atindex{CHECK_UNQUOTED}
@vrindex at_status
-Execute a test by performing given shell @var{commands}. @var{commands}
-is output as-is, so shell expansions are honored. These commands
-should normally exit with @var{status}, while producing expected
+Execute a test by performing given shell @var{commands} in a subshell.
+...@var{commands} is output as-is, so shell expansions are honored. These
+commands should normally exit with @var{status}, while producing expected
@var{stdout} and @var{stderr} contents. If @var{commands} exit with
unexpected status 77, then the rest of the test group is skipped. If
@var{commands} exit with unexpected status 99, then the test group is
-immediately failed. Otherwise, if this test
-fails, run shell commands @var{run-if-fail} or, if this test passes, run shell
-commands @var{run-if-pass}. At the beginning of @var{run-if-fail} and
-...@var{run-if-pass}, the status of @var{commands} is available in the
-...@code{at_status} shell variable.
+immediately failed. Otherwise, if this test fails, run shell commands
+...@var{run-if-fail} or, if this test passes, run shell commands
+...@var{run-if-pass}, both inside the current shell execution environment.
+At the beginning of @var{run-if-fail} and @var{run-if-pass}, the status of
+...@var{commands} is available in the @code{at_status} shell variable.
This macro must be invoked in between @code{AT_SETUP} and @code{AT_CLEANUP}.
diff --git a/tests/autotest.at b/tests/autotest.at
index 725da38..ab04dbe 100644
--- a/tests/autotest.at
+++ b/tests/autotest.at
@@ -432,6 +432,25 @@ AT_CHECK([grep 'run-if-pass: 42' stdout], [], [ignore])
])
+AT_CHECK_AT_TEST([AT@t...@_check execution environment],
+ [dnl The first test should fail, so we enter RUN-IF-FAIL.
+ AT_CHECK([test $state != before], [], [], [],
+ [state=run-if-fail
+AT_CHECK([:]) dnl need this so we do not bail out at this point.
+])
+ dnl This should pass, so we enter RUN-IF-PASS.
+ AT_CHECK([test $state = run-if-fail], [], [], [], [],
+ [state=run-if-pass])
+ AT_CHECK([test $state = run-if-pass])
+ dnl However, COMMANDS are run inside a subshell, so do not change state.
+ AT_CHECK([state=broken; false], [], [], [],
+ [AT_CHECK([test $state = run-if-pass])])
+ AT_CHECK([state=broken], [], [], [], [],
+ [AT_CHECK([test $state = run-if-pass])])
+ ],
+ [], [], [], [], [], [], [state=before])
+
+
AT_CHECK_AT_TEST([unquoted output],
[m4_define([backtick], [`])
a=a
Re: plans?
* Paolo Bonzini wrote on Tue, Aug 31, 2010 at 12:22:17PM CEST: We _really_, _really_ need a stable branch of Autoconf where every regression is treated the same way as security problems and released in a matter of days. And where only regressions are fixed using the _least invasive_ approach. FWIW, I agree that a stable branch would be a good idea. Or, if that is less work, start one in presence of regressions and just cherry-pick from master. (In the latter case, stable would have to be fake-merged or rewound after new feature releases.) It probably won't have to be a long-term branch, as major issues are usually found fairly quickly. Cheers, Ralf
Re: [PATCH 0/2] cleanup $tmp usage
Hi Eric, * Eric Blake wrote on Mon, Aug 30, 2010 at 06:32:37PM CEST: --- c/tests/torture.at +++ w/tests/torture.at +AT_CHECK_MACRO([AC_CONFIG_COMMANDS with temporary directory], +[[AC_CONFIG_COMMANDS([foo], [ +case $ACTION in + use) +echo $tmp tmpdir +test -d $tmp || AC_MSG_ERROR([No $tmp directory]) +echo garbage-in $tmp/garbage-out +;; + corrupt) +echo $tmp tmpdir +tmp=/nosuch This isn't without danger, as two undesirable things can happen when some code in config.status does try to write to $tmp after this: first, the user compiling as root might be annoyed at extra junk in /, second, some user with a security-enhanced distribution (forgot which, sorry) may report that Autoconf tried to violate its allowed name space. I don't recall which of the autotools I saw such a report for. Cheers, Ralf +;; + *) ;; +esac +]) +]], [ +AT_CHECK([test ! -f tmpdir]) +AT_CHECK([ACTION=use ./config.status], [], [ignore]) +AT_CHECK([test -s tmpdir test ! -d `cat tmpdir`]) +AT_CHECK([ACTION=corrupt ./config.status], [], [ignore]) +AT_CHECK([test -s tmpdir test ! -d `cat tmpdir`])
Re: [PATCH 2/2] config.status: minimize use of $tmp
Hi Eric,
* Eric Blake wrote on Mon, Aug 30, 2010 at 06:41:47PM CEST:
On 08/27/2010 01:24 PM, Eric Blake wrote:
- tmp=
+ tmp= ac_tmp=
trap 'exit_status=$?
- { test -z $tmp || test ! -d $tmp || rm -fr $tmp; } exit
$exit_status
+ { test ! -d ${ac_tmp:=$tmp} || rm -fr $ac_tmp; } exit $exit_status
And then I promptly used it incorrectly. Per what we just
documented, we cannot assume that ${a=b} takes effect in the parent
shell if we are executing a child command like test
I don't follow this. Surely that Posix reference hints at
http://austingroupbugs.net/view.php?id=255
and is meant for assignments *before* commands only, as in for example
ac_tmp=$tmp test ! -d $ac_tmp
but not the code above.
Can you help me understand?
Thanks,
Ralf
${var:+quo ted} and similar, inside unquoted here-docs
With Solaris 10 sh (and others):
cat EOF
${var-quo ted}
EOF
quo ted
Whereas with bash (and others):
quo ted
This shows up in some of the log files in the Configuring libtool line:
http://autobuild.josefsson.org/libtool/log-201008291316239205000.txt
Eric, did you have this in your recent autoconf.texi additions already?
It can be a problem for all of the stuff that gets expanded into here
documents.
Thanks,
Ralf
Re: [PATCH 0/5] more aggressive on ${a:-b}
* Eric Blake wrote on Fri, Aug 27, 2010 at 06:30:15PM CEST: On 08/26/2010 11:27 AM, Ralf Wildenhues wrote: If you (still) need somebody to test IRIX, OSF, Solaris 2.6, AIX, please ping me. I definitely would feel a bit less worried if these changes were thoroughly tested before the next release. I've gone ahead and pushed the remaining patch from this series, if you'd like to start widening the test exposure. So my pending patches are not ok for 2.68 then? Thanks, Ralf
Re: [PATCHv2] docs: mention another issue with variable expansion
* Eric Blake wrote on Thu, Aug 26, 2010 at 07:01:30PM CEST:
+Perhaps the easiest way to work around quoting issues in a manner
+portable to all shells is to place the results in a temporary variable,
+then use @samp{$tmp} as the @var{value}, rather than trying to inline
+the expression needing quoting.
I wish you wouldn't use nor promote tmp as temporary variable name,
nor as a temporary macro name in tests/m4sh.at, given that it's already
documented as name of a temporary directory to use in config.status.
+...@example
+$ @kbd{/bin/sh -c 'tmp=a b\'\''@}\\; echo $...@{a-$tmp@}'}
+b c'@}\
+$ @kbd{ksh -c 'tmp=a b\'\''@}\\; echo $...@{a-$tmp@}'}
+b c'@}\
+$ @kbd{bash -c 'tmp=a b\'\''@}\\; echo $...@{a-$tmp@}'}
+b c'@}\
+...@end example
[...]
Cheers,
Ralf
Re: [PATCH] autoconf: warn if AC_*_IFELSE lacks complete program
* Eric Blake wrote on Fri, Aug 27, 2010 at 03:59:00PM CEST: On 08/26/2010 11:24 PM, Ralf Wildenhues wrote: Is m4_pushdef([M]) m4_define([M]) m4_popdef([M]) documented to work and do the expected (what would that be?) thing? Yes - [...] (Some other m4 implementations are documented where m4_define wipes out the entire pushdef stack, rather than the top-most definition on the stack, and POSIX allows that alternate semantic, but it would break m4sugar.) Ah, that bit of semantics had evaded me so far. On the other hand, AC_COMPILE_IFELSE(AC_LANG_DEFINES_PROVIDED) (note the missing quoting) expands to: m4_define([a],[nowarn])m4_pushdef([a],[warn])a()m4_popdef([a]) and still issues a warning, because the AC_LANG_DEFINES_PROVIDED was expanded too early, and the expansion of a is still tied to the [warn] from the pushdef. Yup, seeing that in a couple of cases in Libtool, which I'm going to fix next. Thanks, Ralf
Re: [PATCH] autoconf: warn if AC_*_IFELSE lacks complete program
* Eric Blake wrote on Thu, Aug 26, 2010 at 11:13:02PM CEST: * lib/autoconf/fortran.m4 (AC_FC_FREEFORM, AC_FC_FIXEDFORM) (AC_FC_LINE_LENGTH, __AC_FC_NAME_MANGLING): Intentionally bypass AC_LANG_SOURCE. Rather than uglifying all Fortran tests (which would need to be done in a number of third-party macros as well), how about turning off the warning for Fortran 77 and Fortran, for which Autoconf doesn't provide pre-processing functionality yet anyway? Thanks, Ralf
Re: Try to update config.cache atomically; respect symlinks.
* Eric Blake wrote on Fri, Aug 27, 2010 at 07:36:08PM CEST: On 08/16/2010 02:03 PM, Ralf Wildenhues wrote: * doc/autoconf.texi (Cache Files): Leftover temporary cache files may be deleted by the user. I think the problem is rare enough, and agree with your sentiment of not documenting it (at least, not for now). Maybe if we ever get reports of someone wondering about stale files... So I had the patch in with the documentation bits anyway, sorry about the glitch. I think it's ok though. No, because the last AT_CHECK is designed to catch both cases. I've added a comment to this end now, see below. Looks good with that comment; I'm okay if you go ahead and apply this patch. Thanks, done. Ralf
Re: [PATCH 0/2] cleanup $tmp usage
* Eric Blake wrote on Fri, Aug 27, 2010 at 09:24:49PM CEST: I wish you wouldn't use nor promote tmp as temporary variable name, nor as a temporary macro name in tests/m4sh.at, given that it's already documented as name of a temporary directory to use in config.status. Good point. I'm scrubbing that now... Done. I'll wait till Monday to push, though, in case you have further comments. Looks good to me, thanks! Eric Blake (2): docs: avoid use of $tmp outside of config.status use config.status: minimize use of $tmp Cheers, Ralf
Re: [PATCH 0/5] more aggressive on ${a:-b}
Hi Eric,
* Eric Blake wrote on Thu, Aug 26, 2010 at 01:18:16AM CEST:
On cygwin, attempts to do a glob() with a filename that contains
a backslash can issue a warning; but I have been unable to reliably
reproduce that in my environment (otherwise, I would have used it
as an example in the second patch). But see these links for an
example of where unintended globbing matters:
http://cygwin.com/ml/cygwin/2009-04/msg00531.html
I'm sure somebody thought that it would be a good idea to print that
warning, I can't imagine any reason that wouldn't outweigh its downsides
now though. Do you have a link to the corresponding implementation
discussion? Thanks.
Eric Blake (5):
m4sh: fix some namespace safety issues
docs: mention cost of globbing during variable expansion
I'm replying to that one separately.
tests: improve some shell assumption testing
m4sh: reduce size of AS_VAR_TEST_SET
m4sh: assume ${a:-b} support
This one contains merge conflict markers, so cannot have been tested
in this spelling. The tests in this one assume that unset works (I'm
not judging that, just stating that it's the case).
If you (still) need somebody to test IRIX, OSF, Solaris 2.6, AIX, please
ping me. I definitely would feel a bit less worried if these changes
were thoroughly tested before the next release.
Thanks,
Ralf
Re: [PATCH 2/5] docs: mention cost of globbing during variable expansion
Hi Eric,
* Eric Blake wrote on Thu, Aug 26, 2010 at 01:18:18AM CEST:
* doc/autoconf.texi (Shell Substitutions) ${var=literal}:
Recommend quoting substitutions that might trigger globbing.
(Limitations of Builtins) :: Likewise.
* bin/autoconf.as: Follow our own advice.
* lib/autoconf/functions.m4 (AC_FUNC_SELECT_ARGTYPES): Likewise.
* lib/autoconf/general.m4 (_AC_INIT_PARSE_ARGS): Likewise.
* lib/autoconf/status.m4 (AC_OUTPUT): Likewise.
* lib/autotest/general.m4 (_AT_FINISH): Likewise.
* lib/m4sugar/m4sh.m4 (AS_TMPDIR): Likewise.
* tests/autotest.at (parallel autotest and signal handling):
Likewise.
* tests/c.at (AC_OPENMP and C, AC_OPENMP and C++): Likewise.
* tests/foreign.at (shtool): Likewise.
* tests/fortran.at: Likewise.
* tests/tools.at (autom4te preselections): Likewise.
* tests/torture.at (VPATH): Likewise.
while you found most bugs in the code part of this patch already, ...
2010-08-25 Eric Blake ebl...@redhat.com
+ docs: mention cost of globbing during variable expansion
[...]
+
+2010-08-25 Eric Blake ebl...@redhat.com
+
m4sh: fix some namespace safety issues
... and somebody should fix git-merge-changelog adding extra header
lines ...
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
[...]
@@ -15441,7 +15467,7 @@ Shell Substitutions
@example
default=yu,yaa
-: $...@{var=$default@}
+: $...@{var=$default@}
@end example
@noindent
@@ -15467,7 +15493,7 @@ Shell Substitutions
@example
default=a b c
-: $...@{list=$default@}
+: $...@{list=$default@}
for c in $list; do
echo $c
done
@@ -15720,7 +15746,7 @@ Assignments
brace, use:
@example
-: $...@{var='my literal'@}
+: $...@{var='my literal'@}
@end example
@item
@@ -15729,7 +15755,7 @@ Assignments
(i.e., it's not a list), then use:
@example
-: $...@{var=$default@}
+: $...@{var=$default@}
@end example
@item
... it doesn't look to safe to change code snippets in the manual that
describe quoting bugs in old shells, which is true for at least some of
the above. I don't know if you've fixed all instances in followup
patches already, but at least I haven't seen a log entry that states
this.
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1453,7 +1453,7 @@ AC_CACHE_CHECK([types of arguments for select],
done
done
# Provide a safe default value.
-: ${ac_cv_func_select_args='int,int *,struct timeval *'}
+: ${ac_cv_func_select_args='int,int *,struct timeval *'}
This one looks buggy too (and is not reverted yet).
Cheers,
Ralf
