Re: link and run a (fortran) program redirecting its stdout/stderr
At Tuesday 13 October 2009, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Stefano Lattarini wrote on Mon, Oct 12, 2009 at 09:20:04PM CEST: I have to compile and link a Fortran 77 test program. and then run it redirecting its stdout/stderr (I need to do so to verify that the `stop' builtin is silent when called without arguments -- unfortunately this is not always the case, e.g. when using gfortran-4.0). Can you explain what this means or does? If this is similar to checking for the declaration of a C function, then it should be handled similarly, i.e., by a suitable compile or link test, rather than by trying to parse compiler and/or output. OK, I must admit that the description of my intentions was really badly expressed. I'll try to restate them more clearly. I *don't* care about compiler warnings or messages at compile time. What matters to me is that the *program generated* by the compiler, when executed, is not too verbose w.r.t. the `stop' builtin. For example, assume that I have a fortran source using the `stop' builtin *without arguments*, as in: $ cat foo.f program foo stop end If I compile the `foo.f' file into the `foo.exe' executable: $ f77 -o foo.exe foo.f then I'd expect that running `foo.exe' will simply produce a sucessful exit status, and *no message* on stdout or stderr. This is indeed what happens with modern gfortran (version 4.3) and with the `fort77' compiler (wrapper arounf f2c + gcc): the generated program behaves as expected, being completely quiet. Unfortunately, the foo.exe produced by gfortran-4.0 ends up doing someting like this: $ gfortran-4.0 -o foo.exe foo.f # no errors or warnings here $ ./foo.exe # this produces the following unwanted message STOP 0 To summarize, what I must verify is that the Fortran compiler, when processing a call to `stop' *without arguments*, does not produce code which, when executed, will end up writing STOP 0 or sometinhg similar on stdout/stderr. The only way I can think of to accomplish this is to compile and link a simple test program (like the `foo.f' above), run it redirecting its output, and analyze this output. And here I'm stuck, for the problems described in my previous mail. Hope things are clearer now. Thanks, Stefano ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: silent-rules
On Tue, 13 Oct 2009, Ralf Corsepius wrote: The problem is verifying correctness of building packages in batches. i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls etc. for correctness (NB: A package, which compiles without warning doesn't mean it is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some packages are enabling it by default because it looks like Linux and Linux is cool. This is exactly the problem that I was concerned about and why I fought to ensure that it is not enabled by default. Unfortunately, it was made very easy for a package author to enable by default and some package authors are now doing so even though it makes open source software seem confusing and inconsistent. It means automake is pushing around package maintainers to modify their packages to automake's behavioral changes. Quite annoying indeed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: silent-rules
On 10/13/2009 04:49 PM, Bob Friesenhahn wrote: On Tue, 13 Oct 2009, Ralf Corsepius wrote: The problem is verifying correctness of building packages in batches. i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls etc. for correctness (NB: A package, which compiles without warning doesn't mean it is being built correctly.) What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some packages are enabling it by default Indeed. What makes the situation worse is some upstreams shipping common aclocal-macros which enable it by default. This cause quite some amount of surprises when analysing buildlogs of packages which for whatever reasons run autoreconf/autogen.sh. because it looks like Linux and Linux is cool. :=) Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: regenerating a script specified in AC_CONFIG_FILES
On Mon, Oct 12, 2009 at 23:48, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Thanks. The rebuild rule is generated alright, but nothing depends on the output file. So adding all-local: git_version to lib/Makefile.am would be one possibility. In your case, you should add git_version as prerequisite to LALVCSInfo.h. To let rebuilding keep the right file mode, write this in configure.ac: AC_CONFIG_FILES([lib/git_version], [chmod +x lib/git_version]) replacing the two parts you currently have for this file. Thanks Ralf, thats working great now! Cheers Adam ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: link and run a (fortran) program redirecting its stdout/stderr
* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST: What matters to me is that the *program generated* by the compiler, when executed, is not too verbose w.r.t. the `stop' builtin. Then you should be able to use AC_RUN_IFELSE. To allow for cross compilation, in the fourth argument you could try to find out which versions of gfortran have this issue, and check for those versions there (probably easiest done by GCC-specific preprocessor conditionals). HTH. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: link and run a (fortran) program redirecting its stdout/stderr
At Tuesday 13 October 2009, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST: What matters to me is that the *program generated* by the compiler, when executed, is not too verbose w.r.t. the `stop' builtin. Then you should be able to use AC_RUN_IFELSE. But in the documentation of AC_RUN_IFELSE, as found at: http://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime I can't find any mention of files where the stdout/stderr of the test program is saved. And I known in advance that the test program will succeed: what I must verify is that it won't write anything on stdout or stderr. In this respect, AC_RUN_IFELSE does not seem helpful. Was I misunderstood, or am I missing something? To allow for cross compilation, in the fourth argument you could try to find out which versions of gfortran have this issue, and check for those versions there (probably easiest done by GCC-specific preprocessor conditionals). Luckily, cross compilation is not an issue here: my package is a simple testsuite for ratfor, and I need the fortran compiler only to build test programs from fortran sources generated by ratfor; this test programs must then be run on the spot, so that a native compiler is needed anyway. Regards, Stefano ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
cross-compilation tool detection
This mail being caused by having received the warning quoted below: configure: WARNING: In the future, Autoconf will not detect cross-tools whose name does not start with the host triplet. If you think this configuration is useful to you, please write to autoc...@gnu.org. I indeed 'think' that naming programs according to any taxonomy I might consider to be convenient, possibly including no taxonomy at all (why shouldn't I call a cross-compiler 'Julia', should I so desire?) is useful to me. Kind of a weird question. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
[GNU Autoconf 2.64] testsuite: 180 failed
Dear GNU Staffs Hello, here is 'make check' failed-report on 08/10/2009 11:00 JST. I hope this report will be useful to repair. Thanks a lot for your works, Nozomi KATO k...@interlink-j.com testsuite.log Description: Binary data
Re: cross-compilation tool detection
On Tue, 13 Oct 2009, Rainer Weikusat wrote: I indeed 'think' that naming programs according to any taxonomy I might consider to be convenient, possibly including no taxonomy at all (why shouldn't I call a cross-compiler 'Julia', should I so desire?) is useful to me. You are free to call your compiler anything you like but in the future your code might not compile any more. Since the build host also usually offers compilation tools, it is quite useful if each set of tools is clearly demarked by a naming convention so that the correct ones are used. Use symbolic links to establish one without modifying your tool installation. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation tool detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Rainer Weikusat on 10/13/2009 9:49 AM: This mail being caused by having received the warning quoted below: configure: WARNING: In the future, Autoconf will not detect cross-tools whose name does not start with the host triplet. If you think this configuration is useful to you, please write to autoc...@gnu.org. If you regenerate your configure file with a newer autoconf, that particular message has been reworded to not sound so scary or severe; we have conceded that some people insist on running with non-triplet-prefixed cross-tools, at which point the burden is on the user to get the calling conventions right. We still recommend that you use target-triplet-symlink names, if only to make your life with cross-compilation less prone to unintended bugs. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrVIXQACgkQ84KuGfSFAYAcZwCfYylyfSh8prwGISeeFYSCbn4a 2aAAnjr7Ir4FoI4HsCGYNcqy8gd09xan =vsvf -END PGP SIGNATURE- ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: silent-rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 10/13/2009 9:20 AM: What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some packages are enabling it by default But YOU can still disable it by default, by writing your packaging automation tools to supply --disable-silent-rules as part of calling ./configure, and/or writing an appropriate config.site. In other words, the person running ./configure STILL has the option to choose YOUR desired default, even if it is different than the package author's desired default. The use of silent-rules is an option, not a mandate. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrVIjoACgkQ84KuGfSFAYBm1ACbB9ySznASW/iwTtoWtJKHjqzW gTsAnjr5gWKg/ZwTOZCjUKZYUiS9A4jI =hAug -END PGP SIGNATURE- ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Is there a macro to write an arbitrary file?
We have a makefile in a project, which works well. In the short term at least, we do not want to use autoconf to create a makefile, but instead use our own. However, it would be nice to have a configure script at the top, which at least supports --help and a few other things like that. But we do not want it to create a makefile in the usual way. Is it possible to create a configure.ac which sends it makefile to /dev/null, and instead creates one we want. Currently the first two lines of the makefile are: all: cd spkg ./install all 21 | tee -a ../install.log so would we create a configure script that has exactly that in it. A bit like echo all: makefile echo cd spkg ./install all 21 | tee -a ../install.log makefile (I'm ignoring the fact some of this would need escaping) Since a configure script is basically a shell script, I assume one could just append one the end rm rakefile echo all: makefile echo cd spkg ./install all 21 | tee -a ../install.log makefile etc but if there is a neater way, using autoconf macros, that would be helpful. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: silent-rules
On 10/14/2009 02:58 AM, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Corsepius on 10/13/2009 9:20 AM: What work does it cause except for using --disable-silent-rules at configure time or V=1 at make time? Exactly this is the problem. The problem isn't the support for silent rules. The problem is that some packages are enabling it by default But YOU can still disable it by default, by writing your packaging automation tools to supply --disable-silent-rules as part of calling ./configure, and/or writing an appropriate config.site. In other words, the person running ./configure STILL has the option to choose YOUR desired default, even if it is different than the package author's desired default. Exactly what I said in a previous mail: Automake is pushing around package maintainers to modify their packages to automake's behavioral changes. (Here package maintainer == Package installers) The use of silent-rules is an option, not a mandate. IMO, upstream maintainers, who use silent rules, don't have much clues about what they are doing - Their practice is harmful. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Is there a macro to write an arbitrary file?
On Tuesday 13 October 2009 21:13:29 Dr. David Kirkby wrote: We have a makefile in a project, which works well. In the short term at least, we do not want to use autoconf to create a makefile, but instead use our own. However, it would be nice to have a configure script at the top, which at least supports --help and a few other things like that. But we do not want it to create a makefile in the usual way. autoconf isnt tied to any specific file (like Makefile). if you dont want autoconf to create a file, dont list it as an output. $ cat configure.ac AC_INIT(foo) $ autoconf $ ./configure --help -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: Is there a macro to write an arbitrary file?
On Wed, Oct 14, 2009 at 02:13, Dr. David Kirkby david.kir...@onetel.netwrote: We have a makefile in a project, which works well. In the short term at least, we do not want to use autoconf to create a makefile, but instead use our own. However, it would be nice to have a configure script at the top, which at least supports --help and a few other things like that. But we do not want it to create a makefile in the usual way. Is it possible to create a configure.ac which sends it makefile to /dev/null, and instead creates one we want. Currently the first two lines of the makefile are: all: cd spkg ./install all 21 | tee -a ../install.log Hi; First, there's a split you're missing: autoconf makes the configure.ac part and the xx.in -- xx (ie Makefile.in -- Makefile), automake makes the Makefile.am - Makefile.in part. You could simply use autoconf as a you're thinking: AC_INIT(myproject, 0.1) AC_CANONICAL_HOST AC_PROG_INSTALL AC_PROG_MAKE_SET ...etc... ...etc... AC_OUTPUT(Makefile) ... and hand-build your Makefile.in: all: cd spkg ./install all 21 | tee -a ../install.log ... and simply add tokens as you find portability problems. You may decide a few years down-the-road to go with Automake for the portability it offers, but not today. Maybe next month you'll need to replace the tee command with a AC_PROG([tee]) in configure.in and a t...@tee@ in your Makefile.in. Who knows? see also: two links of relatively unstructured replacement stuff: http://www.gnu.org/software/hello/manual/autoconf/Setting-Output-Variables.html#Setting-Output-Variables http://www.gnu.org/software/hello/manual/autoconf/Configuration-Files.html#Configuration-Files Allan -- all...@chickenandporn.com 金鱼 http://linkedin.com/in/goldfish please, no proprietary attachments (http://tinyurl.com/cbgq) Sent from London, Eng, United Kingdom ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
How to test if preprocessor defines foobar in macro?
I'm trying to modify this macro http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4 which attempt to get the number of CPUs in a system. I'd like to extend it to cover Solaris, AIX and HP-UX. It seems sensible to me to only do a test on a platform it will work on, so I think thinking of something like if `uname` = HP-UX write test for HP-UX fi or I could check if __hpux__ is defined or not. Can anyone show me how to modify the above autoconf macro to do the test using either uname, a macro that the pre-processor defines, or other that allows me to execute a bit of code on only one platform. method. There's another macro I've seen used for determine cache sizes of processors. http://www.nongnu.org/autoconf-archive/ax_cache_size.html which depends on the CPU being an x86 one, which it will often not be. I don't fancy the task of trying to work out cache sizes for every processor used on machines running Solaris, AIX or HP-UX, so will try to modify that so it returns a sensible guess (say 1 MB) on processors it does not know about. The test is causing a script to crash on HP-UX. Dave ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: link and run a (fortran) program redirecting its stdout/stderr
* Stefano Lattarini wrote on Tue, Oct 13, 2009 at 08:39:11PM CEST: At Tuesday 13 October 2009, Ralf Wildenhues wrote: * Stefano Lattarini wrote on Tue, Oct 13, 2009 at 03:22:51PM CEST: What matters to me is that the *program generated* by the compiler, when executed, is not too verbose w.r.t. the `stop' builtin. Then you should be able to use AC_RUN_IFELSE. But in the documentation of AC_RUN_IFELSE, as found at: http://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime I can't find any mention of files where the stdout/stderr of the test program is saved. And I known in advance that the test program will succeed: what I must verify is that it won't write anything on stdout or stderr. In this respect, AC_RUN_IFELSE does not seem helpful. Sorry; I forgot to add: In the ACTION-IF-TRUE argument of AC_RUN_IFELSE, you can invoke ./conftest$EXEEXT yourself and see what it does. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to test if preprocessor defines foobar in macro?
* Dr. David Kirkby wrote on Wed, Oct 14, 2009 at 06:36:36AM CEST: http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4 This macro does not look well-designed. It does the wrong thing when cross-compiling, or even only compiling for a different system (which happens to be use the same architecture). A better approach would be to provide the user with a switch, or prefer a user override of CPU_COUNT. If that switch/variable was not used, and cross compilation is not enabled, then one can try to use the $build system features; but even then you should be cautious about the result. which attempt to get the number of CPUs in a system. I'd like to extend it to cover Solaris, AIX and HP-UX. How do you find out this information on those systems? It seems sensible to me to only do a test on a platform it will work on, so I think thinking of something like if `uname` = HP-UX write test for HP-UX fi uname gives you $build system info. AC_CANONICAL_HOST sets $host which helps better, and gives fairly uniform info. See config.guess for a number of strings to match. There's another macro I've seen used for determine cache sizes of processors. http://www.nongnu.org/autoconf-archive/ax_cache_size.html This has similar problems. which depends on the CPU being an x86 one, Not only that. IIUC it also depends on running on non-ancient Linux only. which it will often not be. I don't fancy the task of trying to work out cache sizes for every processor used on machines running Solaris, AIX or HP-UX, so will try to modify that so it returns a sensible guess (say 1 MB) on processors it does not know about. The test is causing a script to crash on HP-UX. HTH. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to test if preprocessor defines foobar in macro?
On Wed, Oct 14, 2009 at 05:36:36AM +0100, Dr. David Kirkby wrote: I'm trying to modify this macro http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_count_cpus.m4 which attempt to get the number of CPUs in a system. I'd like to extend it to cover Solaris, AIX and HP-UX. It seems sensible to me to only do a test on a platform it will work on, so I think thinking of something like if `uname` = HP-UX write test for HP-UX fi or I could check if __hpux__ is defined or not. See AC_CANONICAL_HOST for the way of identifying the host platform. However, we generally omit explicit assumptions about the right test for a certain system type. Instead, try each test unconditionally and use the first one that works. The code you reference currently does this. Consider checking processor count and cache characteristics at runtime. If a OS distribution ships binaries of your software, they will run on a wide range of processor configurations. You might need `configure'-time checks to verify the availability of the APIs you would use at runtime. pgpR4ZKqHqIba.pgp Description: PGP signature ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: How to test if preprocessor defines foobar in macro?
On Wednesday 14 October 2009 00:36:36 Dr. David Kirkby wrote: I'm trying to modify this macro http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m 4/ax_count_cpus.m4 which attempt to get the number of CPUs in a system. I'd like to extend it to cover Solaris, AIX and HP-UX. there are so many reasons why this is wrong (some of which people have pointed out). you havent really said why you want this information, but presumably it isnt for usage in the configure script (since that's about the only place this info would be valid). if it's being passed to source code, you should be querying the proc count at runtime with sysconf(_SC_NPROCESSORS_CONF). if your system isnt POSIX complaint, then usually it provides some other way of getting this info. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
