flags for different fortran compilers
Dear autoconf community, I am trying to replicate the install of an existing package using autoconf. We need the package to be able to compile with a wide variety of compilers. In the original setup this was done by the make.macros file that would give a list of flags for each compiler. From what I understand autoconf has a few built in macros that help with the choice of flags such as AC_FC_FREEFORM, but unless I am missing something that won't cover all the flags. What is then the recommended way to handle this? I could have a bunch of 'case' in my configure.ac file but I wanted to see if there wouldn't be a more elegant way... I am new to fortran too so that may sound crazy but couldn't there be a library of flag for known fortran compiler that autoconf could select on the fly like for the free form one? Thanks, Cheers, Eve-Marie -- Eve-Marie Devaliere, MS Senior Science System/Software Engineer Joint Center for Satellite Data Assimilation (JCSDA) The contents of this message are mine personally and do not necessarily reflect any position of NOAA ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: produce *mod with fortran
Thanks Ralph! I am now trying to make my package more portable so I am
working on the part below
Do you need the package to be very portable? If so, I suggest you go to
the Autoconf Macro Archive and grab two Fortran-related macros,
AX_F90_MODULE_EXTENSION and AX_F90_MODULE_FLAG.
We then use roughly the following in configure.ac besides what you
already have:
# Find out how to add to the Fortran include path.
AX_F90_MODULE_FLAG
# The module flag may be -I or so, and some make implementations
# swallow trailing space in variable settings, so we employ a little
# trick.
AC_SUBST([empty], [])
AC_SUBST([FC_MODINC], [$ax_f90_modflag'${empty}'])
# Find out the file name extensions of Fortran module files.
AX_F90_MODULE_EXTENSION
if test x$ax_f90_modext != xunknown; then
FC_MODEXT=$ax_f90_modext
else
FC_MODEXT=$ax_f90_modext
fi
AC_SUBST([FC_MODEXT])
isn't the if/else above the same thing?
When I run autoconf I get:
configure.ac:81: warning: AC_CACHE_VAL(ax_f90_modflag, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_flag.m4:53: AX_F90_MODULE_FLAG is expanded from...
configure.ac:81: the top level
configure.ac:88: warning: AC_CACHE_VAL(ax_f90_modext, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_extension.m4:42: AX_F90_MODULE_EXTENSION is expanded
from...
configure.ac:88: the top level
Did I do anything wrong? I have both AX_F90_MODULE_FLAG and
AX_F90_MODULE_EXTENSION in my m4 directory and ran aclocal -I m4
I also have AC_CONFIG_MACRO_DIR([m4]) in my configure.ac file somewhere
up from that section (it seems to find them anyways)
I get the same warnings running automake and if I keep on going (tried
since there were warnings only) I get the following for ./configure
checking fortran 90 modules inclusion flag... not found
checking fortran 90 modules extension... unknown
./configure: line 4710: syntax error near unexpected token `('
./configure: line 4710: ` $as_echo_n (cached) 6'
Thanks,
Cheers,
Eve-Marie
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Problems when using an alternative autotools installation
Hi, I'm trying to configure for an alternative install of xerces-c on a machine where the version of xerces-c is too old for the software we are developing and where we do not have root access to allow us to install a newer version. This machine also has very old autotools, so I've built autoconf, automake, m4, and libtool in order to do the configuration. My problem is that I'm getting this set of errors when using the new autotools alternative installation when configuring the xerces-c package. I also get these errors when I configure on my laptop using the alternative autotools packages. However, I've played around on my laptop where I can install autotools packages into the default location and have found I only fail the configuration of xerces-c on my laptop when I use the alternative autotools packages and not when they are installed in the default locations. So, there is apparently something wrong with my set-up for using the alternative install. I've been searching the internet for clues and thought I found the answer when I found information about setting ACLOCAL_FLAGS: ACLOCAL_FLAGS=-I /opt/newest_autotools_root/share/aclocal But that didn't make any difference. The searches for information on the internet pointed to gettext and gettext-devel needing to be installed. However, these packages are installed on my laptop where I can reproduce the problem I'm seeing on the machine where I don't have root privileges. SOME EXPERIMENTS I RAN as stated above: When I try to bootstrap libcbtf-xml I see the bootstrap problem (autoconf?) when using the alternative location autotools root. The autotools root has versions: autoconf - 2.65 automake - 1.11.1 m4 - 1.13 libtool - 2.2.6b I can bootstrap on my laptop successfully w/o the autotools_root and I have these versions installed: autoconf - 2.63 automake - 1.11.1 m4 - 1.12 libtool - 2.2.6-11 So, I redid the autotool root components to match the versions in my install and loaded the module. Still get the errors below. So, then I upgraded the versions of the autotools root to: autoconf - 2.68 automake - 1.11.1 m4 - 1.15 libtool - 2.2.10 Still fails as below but autoconf is putting out a lot more messages about what is going on but the errors are still there as well as the warnings. configure:15501: error: possibly undefined macro: AC_LIB_RPATH configure:15514: error: possibly undefined macro: AC_LIB_WITH_FINAL_PREFIX configure:15858: error: possibly undefined macro: AC_LIB_APPENDTOVAR I'm just checking to see if anyone might have any ideas on this. So far, I'm not able to find the correct solution on the internet. Does anyone have any thoughts/ideas on how to solve the problem? Almost seems like something is missing in the autotools module where I setup LD_LIBRARY_PATH and BIN, and now recently ACLOCAL_FLAGS, variables. Are there other variables that should be set? I've inserted the contents the key files mentioned above into this email (below). Any help would be greatly appreciated! Thanks, Jim G ERRORS: [jeg@localhost libcbtf-xml]$ ./bootstrap before aclocal configure.ac:57: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/ax_xercesc.m4:47: AX_XERCESC is expanded from... configure.ac:57: the top level configure.ac:57: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd before libtoolize libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' before autoheader configure.ac:57: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/ax_xercesc.m4:47: AX_XERCESC is expanded from... configure.ac:57: the top level configure.ac:57: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd before automake configure.ac:57: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/ax_xercesc.m4:47: AX_XERCESC is expanded from... configure.ac:57: the top level configure.ac:57: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd before autoconf configure.ac:57: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not m4_defun'd m4/ax_xercesc.m4:47: AX_XERCESC is expanded from... configure.ac:57: the top level configure.ac:57: warning: AC_LIB_RPATH is m4_require'd but not m4_defun'd configure:14975: error: possibly undefined macro: AC_LIB_PREPARE_PREFIX If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:14976: error: possibly undefined macro: AC_LIB_RPATH configure:14989: error: possibly undefined macro:
Re: Problems when using an alternative autotools installation
On Mon, 31 Jan 2011, Jim Galarowicz wrote: So, there is apparently something wrong with my set-up for using the alternative install. I've been searching the internet for clues and thought I found the answer when I found information about setting ACLOCAL_FLAGS: ACLOCAL_FLAGS=-I /opt/newest_autotools_root/share/aclocal But that didn't make any difference. Hi Jim, I have successfully used alternative autotools with (the analogue of) export PATH=/opt/newest_autotools_root/bin:$PATH Regards Peter Breitenlohner p...@mppmu.mpg.de ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: produce *mod with fortran
On Mon, Jan 31, 2011 at 12:21 PM, Eve-Marie Devaliere
eve-marie.devali...@noaa.gov wrote:
Thanks Ralph! I am now trying to make my package more portable so I am
working on the part below
Do you need the package to be very portable? If so, I suggest you go to
the Autoconf Macro Archive and grab two Fortran-related macros,
AX_F90_MODULE_EXTENSION and AX_F90_MODULE_FLAG.
We then use roughly the following in configure.ac besides what you
already have:
# Find out how to add to the Fortran include path.
AX_F90_MODULE_FLAG
# The module flag may be -I or so, and some make implementations
# swallow trailing space in variable settings, so we employ a little
# trick.
AC_SUBST([empty], [])
AC_SUBST([FC_MODINC], [$ax_f90_modflag'${empty}'])
# Find out the file name extensions of Fortran module files.
AX_F90_MODULE_EXTENSION
if test x$ax_f90_modext != xunknown; then
FC_MODEXT=$ax_f90_modext
else
FC_MODEXT=$ax_f90_modext
fi
AC_SUBST([FC_MODEXT])
isn't the if/else above the same thing?
When I run autoconf I get:
configure.ac:81: warning: AC_CACHE_VAL(ax_f90_modflag, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_flag.m4:53: AX_F90_MODULE_FLAG is expanded from...
configure.ac:81: the top level
configure.ac:88: warning: AC_CACHE_VAL(ax_f90_modext, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_extension.m4:42: AX_F90_MODULE_EXTENSION is expanded
from...
configure.ac:88: the top level
From where/when did you get the m4 files? Cache variables need the
_cv_ in the name for (at least newer) autoconf to like it. Looks like
this was done back in April of 2009? Make sure you update the
configure.ac code above for the variable names.
commit 2673212c84ed131e9014832005277da6513aabeb
Author: Luc Maisonobe l...@spaceroots.org
Date: Sun Apr 19 13:05:55 2009 +0200
AX_F90_*: fix cached variable warnings
Autoconf 2.63 generates warnings when cached variable names have no _cv_
in them.
m4/ax_f90_internal_headmod.m4 |4 ++--
m4/ax_f90_library.m4 |6 +++---
m4/ax_f90_library_setup.m4|6 +++---
m4/ax_f90_module.m4 |4 ++--
m4/ax_f90_module_extension.m4 | 16
m4/ax_f90_module_flag.m4 | 12 ++--
6 files changed, 24 insertions(+), 24 deletions(-)
If it still fails, what compiler are you using, and can you post the
config.log file?
Chris
Did I do anything wrong? I have both AX_F90_MODULE_FLAG and
AX_F90_MODULE_EXTENSION in my m4 directory and ran aclocal -I m4
I also have AC_CONFIG_MACRO_DIR([m4]) in my configure.ac file somewhere
up from that section (it seems to find them anyways)
I get the same warnings running automake and if I keep on going (tried
since there were warnings only) I get the following for ./configure
checking fortran 90 modules inclusion flag... not found
checking fortran 90 modules extension... unknown
./configure: line 4710: syntax error near unexpected token `('
./configure: line 4710: ` $as_echo_n (cached) 6'
Thanks,
Cheers,
Eve-Marie
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: Problems when using an alternative autotools installation
Hi Peter, Thanks for the information/verification. I'm able to use the alternative autotools for configuring our OpenSpeedShop performance tool components and part of this, new, CBTF project, but not the xerces-c component. So, apparently there is something special about this particular component's configuration that causes the issue I'm seeing? Thanks, Jim G On 01/31/2011 11:35 AM, Peter Breitenlohner wrote: On Mon, 31 Jan 2011, Jim Galarowicz wrote: So, there is apparently something wrong with my set-up for using the alternative install. I've been searching the internet for clues and thought I found the answer when I found information about setting ACLOCAL_FLAGS: ACLOCAL_FLAGS=-I /opt/newest_autotools_root/share/aclocal But that didn't make any difference. Hi Jim, I have successfully used alternative autotools with (the analogue of) export PATH=/opt/newest_autotools_root/bin:$PATH Regards Peter Breitenlohner p...@mppmu.mpg.de ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Problems when using an alternative autotools installation
On 01/31/2011 10:22 AM, Jim Galarowicz wrote: Still fails as below but autoconf is putting out a lot more messages about what is going on but the errors are still there as well as the warnings. configure:15501: error: possibly undefined macro: AC_LIB_RPATH AC_LIB_RPATH is not provided by autoconf itself (I _really_ wish third party macro providers would quit stealing autoconf's namespace). What this means is that you probably installed some other package that installed its own copy of a file that provides AC_LIB_RPATH in the /old/path/share/aclocal directory, and that you need to either copy this .m4 file into your new /opt/newest_autotools_root/share/aclocal, or else add a redirect file /opt/newest_autotools_root/share/aclocal/dirlist that tells aclocal all other directories to look in (aclocal is an automake tool, not an autoconf one, so I'm pointing you to the automake manual): http://www.gnu.org/software/automake/manual/automake.html#Macro-Search-Path configure:15514: error: possibly undefined macro: AC_LIB_WITH_FINAL_PREFIX configure:15858: error: possibly undefined macro: AC_LIB_APPENDTOVAR Likewise, two more macros not provided by autoconf itself. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Problems when using an alternative autotools installation
Hi Eric, Thanks! I had just found this URL: http://lists.gnupg.org/pipermail/gnupg-devel/2008-November/024658.html that points to similar information, but the reasons were not explained as well as you have explained them. I copied: 68 -rw-rw-r--. 1 jeg jeg 68973 2011-01-31 11:53 lib-prefix.m4 96 -rw-rw-r--. 1 jeg jeg 95779 2011-01-31 11:53 gettext.m4 164 -rw-rw-r--. 1 jeg jeg 164640 2011-01-31 11:54 lib-link.m4 52 -rw-rw-r--. 1 jeg jeg 49320 2011-01-31 11:54 lib-ld.m4 into the libcbtf-xml/m4 directory and the errors are gone. But, I believe you are saying they should really be added to the alternative autotools install directory aclocal subdirectory: /opt/newest_autotools_root/share/aclocal. I will try that. Thanks very much for this information! Jim G [jeg@localhost libcbtf-xml]$ ls /opt/newest_autotools_root/share/aclocal* /opt/newest_autotools_root/share/aclocal: argz.m4 libtool.m4 ltdl.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4 /opt/newest_autotools_root/share/aclocal-1.11: amversion.m4 cond.m4 header.m4 lispdir.m4 mkdirp.m4 options.m4 sanity.m4upc.m4 as.m4 depend.m4 init.m4maintainer.m4 multi.m4 protos.m4 silent.m4vala.m4 auxdir.m4 depout.m4 install-sh.m4 make.m4obsolete.m4 python.m4 strip.m4 ccstdc.m4 dmalloc.m4 lead-dot.m4minuso.m4 obsol-gt.m4 regex.m4substnot.m4 cond-if.m4gcj.m4 lex.m4 missing.m4 obsol-lt.m4 runlog.m4 tar.m4 [jeg@localhost libcbtf-xml]$ ls /usr/share/aclocal* /usr/share/aclocal: alsa.m4glib-gettext.m4 intlmacosx.m4 lib-ld.m4 ltsugar.m4 uintmax_t.m4 argz.m4gnome-common.m4 intltool.m4 lib-link.m4 ltversion.m4 visibility.m4 bison-i18n.m4 gnome-compiler-flags.m4 intmax.m4 lib-prefix.m4 nls.m4 wchar_t.m4 codeset.m4 gnome-doc-utils.m4 inttypes_h.m4 libtool.m4 ORBit2.m4wint_t.m4 fontutil.m4gpg-error.m4 inttypes-pri.m4 libxml.m4 pkg.m4 xorg-macros.m4 freetype2.m4 gtk-doc.m4 lcmessage.m4lock.m4 po.m4xsize.m4 gettext.m4 iconv.m4 libcurl.m4 longlong.m4 printf-posix.m4 xtrans.m4 glib-2.0.m4intdiv0.m4 libgcrypt.m4ltdl.m4 progtest.m4 glibc21.m4 intldir.m4 libgnutls-extra.m4 lt~obsolete.m4 size_max.m4 glibc2.m4 intl.m4 libgnutls.m4ltoptions.m4 stdint_h.m4 /usr/share/aclocal-1.11: amversion.m4 cond.m4 header.m4 lispdir.m4 mkdirp.m4 options.m4 sanity.m4upc.m4 as.m4 depend.m4 init.m4maintainer.m4 multi.m4 protos.m4 silent.m4vala.m4 auxdir.m4 depout.m4 install-sh.m4 make.m4obsolete.m4 python.m4 strip.m4 ccstdc.m4 dmalloc.m4 lead-dot.m4minuso.m4 obsol-gt.m4 regex.m4substnot.m4 cond-if.m4gcj.m4 lex.m4 missing.m4 obsol-lt.m4 runlog.m4 tar.m4 /usr/share/aclocal-1.4: amversion.m4 dmalloc.m4 init.m4 maintainer.m4 multi.m4 ptrdiff.m4 strtod.m4 ccstdc.m4 error.m4lex.m4 missing.m4 obstack.m4 regex.m4termios.m4 cond.m4 header.m4 lispdir.m4 mktime.m4 protos.m4 sanity.m4 winsz.m4 /usr/share/aclocal-1.5: as.m4 depend.m4 gcj.m4 lex.m4 minuso.m4 protos.m4 sanity.m4 winsz.m4 auxdir.m4 depout.m4 header.m4 lispdir.m4 missing.m4 ptrdiff.m4 strip.m4 ccstdc.m4 dmalloc.m4 init.m4maintainer.m4 multi.m4 python.m4 strtod.m4 cond.m4error.m4install-sh.m4 make.m4obstack.m4 regex.m4termios.m4 /usr/share/aclocal-1.6: amversion.m4 cond.m4 gcj.m4 lex.m4 minuso.m4 protos.m4 sanity.m4 as.m4 depend.m4 header.m4 lispdir.m4 missing.m4 python.m4 strip.m4 auxdir.m4 depout.m4 init.m4maintainer.m4 multi.m4 regex.m4 termios.m4 ccstdc.m4 dmalloc.m4 install-sh.m4 make.m4options.m4 runlog.m4 winsz.m4 /usr/share/aclocal-1.7: amversion.m4 cond.m4 gcj.m4 lead-dot.m4make.m4 obsolete.m4 protos.m4 sanity.m4 as.m4 depend.m4 header.m4 lex.m4 minuso.m4 obsol-gt.m4 python.m4 strip.m4 auxdir.m4 depout.m4 init.m4lispdir.m4 missing.m4 obsol-lt.m4 regex.m4 ccstdc.m4 dmalloc.m4 install-sh.m4 maintainer.m4 multi.m4 options.m4 runlog.m4 On 01/31/2011 11:58 AM, Eric Blake wrote: On 01/31/2011 10:22 AM, Jim Galarowicz wrote: Still fails as below but autoconf is putting out a lot more messages about what is going on but the errors are still there as well as the warnings. configure:15501: error: possibly undefined macro: AC_LIB_RPATH AC_LIB_RPATH is not provided by autoconf itself (I _really_ wish third party macro providers would quit stealing autoconf's namespace). What this means is that you probably installed
Re: produce *mod with fortran
Thanks Chris, you were right on it. I had downloaded it from sourceforge
but yes it was apparently an older file
Thanks,
Cheers,
Eve-Marie
Christopher Hulbert said the following on 1/31/2011 12:40 PM:
On Mon, Jan 31, 2011 at 12:21 PM, Eve-Marie Devaliere
eve-marie.devali...@noaa.gov wrote:
Thanks Ralph! I am now trying to make my package more portable so I am
working on the part below
Do you need the package to be very portable? If so, I suggest you go to
the Autoconf Macro Archive and grab two Fortran-related macros,
AX_F90_MODULE_EXTENSION and AX_F90_MODULE_FLAG.
We then use roughly the following in configure.ac besides what you
already have:
# Find out how to add to the Fortran include path.
AX_F90_MODULE_FLAG
# The module flag may be -I or so, and some make implementations
# swallow trailing space in variable settings, so we employ a little
# trick.
AC_SUBST([empty], [])
AC_SUBST([FC_MODINC], [$ax_f90_modflag'${empty}'])
# Find out the file name extensions of Fortran module files.
AX_F90_MODULE_EXTENSION
if test x$ax_f90_modext != xunknown; then
FC_MODEXT=$ax_f90_modext
else
FC_MODEXT=$ax_f90_modext
fi
AC_SUBST([FC_MODEXT])
isn't the if/else above the same thing?
When I run autoconf I get:
configure.ac:81: warning: AC_CACHE_VAL(ax_f90_modflag, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_flag.m4:53: AX_F90_MODULE_FLAG is expanded from...
configure.ac:81: the top level
configure.ac:88: warning: AC_CACHE_VAL(ax_f90_modext, ...): suspicious
cache-id, must contain _cv_ to be cached
autoconf/general.m4:2047: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2060: AC_CACHE_CHECK is expanded from...
m4/ax_f90_module_extension.m4:42: AX_F90_MODULE_EXTENSION is expanded
from...
configure.ac:88: the top level
From where/when did you get the m4 files? Cache variables need the
_cv_ in the name for (at least newer) autoconf to like it. Looks like
this was done back in April of 2009? Make sure you update the
configure.ac code above for the variable names.
commit 2673212c84ed131e9014832005277da6513aabeb
Author: Luc Maisonobe l...@spaceroots.org
Date: Sun Apr 19 13:05:55 2009 +0200
AX_F90_*: fix cached variable warnings
Autoconf 2.63 generates warnings when cached variable names have no _cv_
in them.
m4/ax_f90_internal_headmod.m4 |4 ++--
m4/ax_f90_library.m4 |6 +++---
m4/ax_f90_library_setup.m4|6 +++---
m4/ax_f90_module.m4 |4 ++--
m4/ax_f90_module_extension.m4 | 16
m4/ax_f90_module_flag.m4 | 12 ++--
6 files changed, 24 insertions(+), 24 deletions(-)
If it still fails, what compiler are you using, and can you post the
config.log file?
Chris
Did I do anything wrong? I have both AX_F90_MODULE_FLAG and
AX_F90_MODULE_EXTENSION in my m4 directory and ran aclocal -I m4
I also have AC_CONFIG_MACRO_DIR([m4]) in my configure.ac file somewhere
up from that section (it seems to find them anyways)
I get the same warnings running automake and if I keep on going (tried
since there were warnings only) I get the following for ./configure
checking fortran 90 modules inclusion flag... not found
checking fortran 90 modules extension... unknown
./configure: line 4710: syntax error near unexpected token `('
./configure: line 4710: ` $as_echo_n (cached) 6'
Thanks,
Cheers,
Eve-Marie
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: flags for different fortran compilers
Hello, * Eve-Marie Devaliere wrote on Mon, Jan 31, 2011 at 05:34:47PM CET: I am trying to replicate the install of an existing package using autoconf. We need the package to be able to compile with a wide variety of compilers. In the original setup this was done by the make.macros file that would give a list of flags for each compiler. From what I understand autoconf has a few built in macros that help with the choice of flags such as AC_FC_FREEFORM, but unless I am missing something that won't cover all the flags. What is then the recommended way to handle this? I could have a bunch of 'case' in my configure.ac file but I wanted to see if there wouldn't be a more elegant way... I am new to fortran too so that may sound crazy but couldn't there be a library of flag for known fortran compiler that autoconf could select on the fly like for the free form one? Which kinds of flags do you need support for? The Autoconf Way of implementing things, when there isn't a predefined macro for some feature, is to try out a set of known compiler switches and select the first one that has the desired features. For example, the AC_FC_FREEFORM macro tries to compile a small free-form source file, and passes one of a few known compiler flags that enable free form. It picks the first one that works. If you can formulate your needs in such a way, then the next hurdle is to overcome the M4 language and a few Autoconf building block macros like AC_COMPILE_IFELSE and AC_LINK_IFELSE. We can help with the latter if the former is clear. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H
The gnulib stdbool module currently arranges to #define HAVE_STDBOOL_H if necessary, but this symbol is never used. This is confusing people who port Emacs to systems that don't run 'configure', and I'd like to remove HAVE_STDBOOL_H from Emacs's src/config.in file. HAVE_STDBOOL_H is defined by Autoconf's AC_HEADER_STDBOOL (and thus by gnulib's, for compatibility with Autoconf). The only gnulib macro that uses AC_HEADER_STDBOOL is gnulib's AM_STDBOOL_H; the latter name is curious, as it implies that the macro belongs to Automake, but it's a gnulib macro. It's a bit untidy. How about the following idea to clean things up a bit? In Gnulib: * Rename gnulib's AC_HEADER_STDBOOL to gl_HEADER_STDBOOL. * Remove the AC_DEFINE([HAVE_STDBOOL_H], ...) from gl_HEADER_STDBOOL. * Rename gnulib's AM_STDBOOL_H to gl_STDBOOL_H. In Autoconf: * Mark AC_HEADER_STDBOOL as obsolescent, and suggest to Autoconf users that in the future they use gnulib if they want to be portable to pre-C99 hosts with respect to stdbool.h. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H
On 01/31/2011 04:47 PM, Paul Eggert wrote: The gnulib stdbool module currently arranges to #define HAVE_STDBOOL_H if necessary, but this symbol is never used. This is confusing people who port Emacs to systems that don't run 'configure', and I'd like to remove HAVE_STDBOOL_H from Emacs's src/config.in file. HAVE_STDBOOL_H is defined by Autoconf's AC_HEADER_STDBOOL (and thus by gnulib's, for compatibility with Autoconf). The only gnulib macro that uses AC_HEADER_STDBOOL is gnulib's AM_STDBOOL_H; the latter name is curious, as it implies that the macro belongs to Automake, but it's a gnulib macro. It's a bit untidy. How about the following idea to clean things up a bit? In Gnulib: * Rename gnulib's AC_HEADER_STDBOOL to gl_HEADER_STDBOOL. * Remove the AC_DEFINE([HAVE_STDBOOL_H], ...) from gl_HEADER_STDBOOL. * Rename gnulib's AM_STDBOOL_H to gl_STDBOOL_H. In Autoconf: * Mark AC_HEADER_STDBOOL as obsolescent, and suggest to Autoconf users that in the future they use gnulib if they want to be portable to pre-C99 hosts with respect to stdbool.h. Works for me; keeping macros like this in sync between the two repositories has been problematic in the past, and it matches precedence of other macros where we have declared the autoconf version obsolete (it will continue to exist, but is no longer guaranteed to be the most up-to-date version, in part because detecting the problems doesn't do much good unless you also work around them, and the workarounds fit better in gnulib's module paradigm). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H
Paul Eggert egg...@cs.ucla.edu writes: In Gnulib: * Rename gnulib's AC_HEADER_STDBOOL to gl_HEADER_STDBOOL. * Remove the AC_DEFINE([HAVE_STDBOOL_H], ...) from gl_HEADER_STDBOOL. * Rename gnulib's AM_STDBOOL_H to gl_STDBOOL_H. In Autoconf: * Mark AC_HEADER_STDBOOL as obsolescent, and suggest to Autoconf users that in the future they use gnulib if they want to be portable to pre-C99 hosts with respect to stdbool.h. Please don't make this last change in Autoconf. AC_HEADER_STDBOOL in Autoconf works well right now for people who do not use gnulib, and I don't think that it's a good idea to mark obsolescent a working Autoconf macro to try to push people towards using gnulib instead. The Autoconf manual already spells out exactly how to use AC_HEADER_STDBOOL correctly, and those instructions work fine, without requiring importing any code from yet another project. In general, please continue to support straight Autoconf users with the macros that are in Autoconf. It feels like there's a somewhat disturbing long-term trend here towards pushing everyone who uses Autoconf into also using gnulib, even if Autoconf-using projects are not particularly interested in or set up to use gnulib. I'm of course agnostic about the gnulib changes, since I don't use gnulib and will happily leave discussion of that to those who do. But given that you're proposing renaming macros in gnulib, I don't see any need to make the Autoconf change as well, since the gnulib macros will have different names and will therefore not need to retain compatibility with the same-named macros in Autoconf. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H
On 02/01/2011 04:15 AM, Russ Allbery wrote: Paul Eggertegg...@cs.ucla.edu writes: In Gnulib: * Rename gnulib's AC_HEADER_STDBOOL to gl_HEADER_STDBOOL. * Remove the AC_DEFINE([HAVE_STDBOOL_H], ...) from gl_HEADER_STDBOOL. * Rename gnulib's AM_STDBOOL_H to gl_STDBOOL_H. In Autoconf: * Mark AC_HEADER_STDBOOL as obsolescent, and suggest to Autoconf users that in the future they use gnulib if they want to be portable to pre-C99 hosts with respect tostdbool.h. Please don't make this last change in Autoconf. AC_HEADER_STDBOOL in Autoconf works well right now for people who do not use gnulib, Agreed. I am one of these users. and I don't think that it's a good idea to mark obsolescent a working Autoconf macro to try to push people towards using gnulib instead. Agreed, again. For real-world projects, gnulib often is not a viable alternative. Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
