Re: bug#16623: PACKAGE vs PACKAGE_TARNAME

On 02/03/2014 12:23 AM, infirit wrote: On Sun, 2 Feb 2014 18:56:01 +0100 infirit wrote: On Sun, 02 Feb 2014 23:21:03 +1000 Peter Johansson wrote: [adding bug-automake] On 02/02/14 12:25, infirit wrote: So for a project we wanted to make the tarball different from from the package name. So we

Re: Blogging about deprecated macros

[Moving to the Automake list, that is the correct place for this dicussion] Reference: On 01/07/2013 04:04 AM, Marko Lindqvist wrote: > FYI > > Recent automake-1.13 release has been keeping me busy as I try to fix > the majority

Re: Blogging about deprecated macros

On 01/07/2013 04:04 AM, Marko Lindqvist wrote: > FYI > > Recent automake-1.13 release has been keeping me busy as I try to fix > the majority (it feels) of FOSS projects upon which it fails, due to > AM_CONFIG_HEADER having been removed. > That had actually been my fault, since I mistakenly didn't

Re: About dynamic configure options.

On 12/13/2012 11:22 PM, Eduardo Costa wrote: > Thanks guys, > > I actually sent a "solution" much like yours Nick. Don't know > why Stefano didn't send my answer. > You mean this part? This might be done by usual means (couldn't do it) or just with some trickery to to inject the string manual

Re: About dynamic configure options.

Hi Eduardo. On 12/11/2012 12:57 AM, Eduardo Costa wrote: > Hi, > > Is it possible at all to have a configure option whose help message can > expand a > variable, or can otherwise accept the output of a command at configure-time? > > For example, imagine this as part of the output of `./configur

Re: Future autoconf package compression

On 11/24/2012 09:16 AM, Marko Lindqvist wrote: > On 2 March 2012 06:45, Eric Blake wrote: >> >> The Autoconf team is considering releasing only .xz files for 2.69; if >> this would be a hardship for you, and you need the .gz or .bz2 release, >> please speak up now. > > I just encountered new arg

Re: Assigning command output to a variable

On 11/19/2012 07:36 PM, Eric Blake wrote: > On 11/19/2012 10:09 AM, Adam Mercer wrote: >> Hi >> >> For one of my projects I need to get the contents of >> /etc/redhat-release during the configure process and assign the >> contents to a variable. I'm currently using the following: >> >> redhat_r

Re: bug#12877: Autoconf, GNU m4 and POSIXLY_CORRECT

On 11/14/2012 12:24 PM, Sebastian Freundt wrote: > "Stefano Lattarini" writes: > > Yes, I will report this issue to the m4 guys. > 1.9a has the -g switch and is newer than 1.4 anyway. > Oh, sorry, I has misread the version number as "1.4.9a" *blush*! I agree

Re: bug#12877: Autoconf, GNU m4 and POSIXLY_CORRECT

tags 12877 - moreinfo tags 12877 notabug close 12877 thanks On 11/14/2012 12:09 PM, Sebastian Freundt wrote: > > "Stefano Lattarini" writes: >> >> On 11/14/2012 07:45 AM, Sebastian Freundt wrote: >>> >>> (GNU) m4 when being called with the variable

Autoconf, GNU m4 and POSIXLY_CORRECT (was: Re: bug#12877: automake error: unrequested trace '')

[+cc autoconf] On 11/14/2012 07:45 AM, Sebastian Freundt wrote: > Stefano Lattarini writes: > >> tags 12877 + moreinfo >> thanks >> >> Hi Sebastian, thanks for the report. >> >> On 11/13/2012 11:30 AM, Sebastian Freundt wrote: >>> shell>

Re: Python macros

On 09/23/2012 08:31 PM, Brandon Invergo wrote: > > [SNIP] > > python.m4 in Automake is much more complete, and these macros are the > direct decendents of that file, but to me at least, it's confusing that > these macros should be implemented in Automake and not in Autoconf (or > Autoconf Archive f

Re: [PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once again

On 08/24/2012 11:43 AM, Stefano Lattarini wrote: > Reference: > <http://lists.gnu.org/archive/html/automake/2012-08/msg00025.html> > > On 08/15/2012 12:16 AM, Stefano Lattarini wrote: >> Hi Bob, I managed to find your old message about "dynamically computing >>

[PATCH] {master} AM_INIT_AUTOMAKE: allow obsolescent two-args invocation once again (was: Re: Dynamic package version numbers with Autoconf and Automake)

Reference: <http://lists.gnu.org/archive/html/automake/2012-08/msg00025.html> On 08/15/2012 12:16 AM, Stefano Lattarini wrote: > Hi Bob, I managed to find your old message about "dynamically computing > package versions for Automake and Autoconf". Some initial comments >

Automake, Autoconf and POSIX shells (was: Re: GraphicsMagick Automake TAP)

[Adding the Automake and Autoconf list, as this might be of public interest] On 08/19/2012 05:48 PM, Bob Friesenhahn wrote: > Something I notice is that Automake's configure.ac contains an > elaborate testing of shells resulting in a AM_TEST_RUNNER_SHELL > definition which is used for the Bourne s

Dynamic package version numbers with Autoconf and Automake (was: Re: Automake 1.12.0b test release)

Hi Bob, I managed to find your old message about "dynamically computing package versions for Automake and Autoconf". Some initial comments follows. I'm adding the Autoconf list in CC:, because I believe this is an Autoconf issue more than an Automake one. On 05/20/2012 12:59 AM, Bob Friesenhahn

Re: [PATCH] config: drop scripts that automake says are not independent

On 06/26/2012 09:12 PM, Eric Blake wrote: > > [SNIP] > > And not mentioned in my proposed commit message, but I specifically kept > mdate-sh as one of the mirrored files, even though Stefano originally > suggested that it might be automake-centric; that particular script is > small enough to be use

Re: [PATCH] yacc, lex: new 'no-ylwrap' option to prevent use of the 'ylwrap' script

Hi Eric. On 06/26/2012 06:27 PM, Akim Demaille wrote: > > Le 26 juin 2012 à 18:18, Eric Blake a écrit : > >> Just from reading this summary, the idea of improving AC_PROG_LEX and >> AC_PROG_YACC to be more useful makes sense, especially if it would make >> automake easier to maintain. What sort

Re: Autoconf caches AC_INIT arguments

Hi Bob. On 05/23/2012 02:17 AM, Bob Friesenhahn wrote: > The forthcoming Automake release is about to break the means I have been > using to automatically version my package (without manually editing > configure.ac) for the past 9 years. > I smell a misunderstanding here: Automake 1.12.1 will only

Re: [FYI] {master} refactor: use modern semantics of 'open'

[SNIP] Eric Blake wrote: >>> >>> Alas, my perl-fu is weak enough that I'm not sure how good my >>> unit-testing attempts would be. But moving the files to a common >>> repository seems doable (how about gnulib?). I replied: >> >> This could be a good "interim" solution, as I the paperwork in pla

Re: [FYI] {master} refactor: use modern semantics of 'open'

Hi Eric, sorry for the delay. On 04/25/2012 01:25 AM, Eric Blake wrote: > > Actually, this appears to make _all_ the XFile uses work; all that > remains broken is places such as bin/autoupdate.in calling raw open > instead of using XFile. > >>> >>> diff --git i/lib/Autom4te/XFile.pm w/lib/Autom4t

Re: [FYI] {master} refactor: use modern semantics of 'open'

Hi Eric, Russ. On 04/25/2012 01:08 AM, Eric Blake wrote: > On 04/24/2012 04:50 PM, Russ Allbery wrote: >> Eric Blake writes: >> >>> Help! I can't release autoconf 2.69 until I figure out how to work >>> around this patch. After updating to the latest shared files, as well >>> as applying this p

Re: autoconf-2.68b released [beta]

On 03/20/2012 06:38 PM, Stefano Lattarini wrote: > Hi Eric, all. > > On 03/02/2012 05:45 AM, Eric Blake wrote: >> The GNU Autoconf team is pleased to announce the beta release of >> Autoconf 2.68b. >> > [SNIP] > > What is the status on this? Is the 2.69 rele

Re: how-to question: architecture dependent source

On 03/23/2012 10:10 AM, Christopher Howard wrote: > On 03/21/2012 03:39 PM, Christopher Howard wrote: >> Hi. I'm still working on learning autotools (been reading through all >> the manuals) so bear with me. There is something I've been trying to >> figure out, and I would appreciate any guidance:

Re: autoconf-2.68b released [beta]

Hi Eric, all. On 03/02/2012 05:45 AM, Eric Blake wrote: > The GNU Autoconf team is pleased to announce the beta release of > Autoconf 2.68b. > [SNIP] What is the status on this? Is the 2.69 release going to appear soon, or there are still loose ends to tie? Regards, Stefano _

Re: [RFC] Could autoconf-generated configure scripts start requiring a POSIX shell?

On 03/04/2012 04:48 AM, Eric Blake wrote: > On 03/03/2012 07:46 PM, Paul Eggert wrote: >> On 03/03/2012 11:01 AM, Stefano Lattarini wrote: >>> would you think about the possibility of making autoconf-generated >>> configure scripts *require* a POSIX shell in order to r

[RFC] Could autoconf-generated configure scripts start requiring a POSIX shell?

Hello autoconfers. I think it's clear to everybody that a "true" POSIX shell has several real advantages over a legacy Bourne shell (like, say, the dreaded Solaris /bin/sh). And I don't know of any non-museum system that doesn't have a POSIX shell *somewhere*. So, what would you think about the p

Re: bug#10898: test-suite output of automake-1.11.3 - it requested I send it to you!

On 02/28/2012 05:51 PM, Eric Blake wrote: > [adding autoconf] > > On 02/28/2012 09:42 AM, Stefano Lattarini wrote: > >>>Ah, likely the famous ksh bug with "$@" and empty arguments: >>> >>> >>> <http://lists.gnu.org/archive/ht

Re: [FYI] {master} maint: assume 'test -x' is portable

On 02/24/2012 12:45 AM, Eric Blake wrote: > On 02/23/2012 04:39 PM, Stefano Lattarini wrote: > > I'll take it from here, if you'd like, > Oh yes, I would :-) > since I've done probes before, so I know where to edit. > Thanks, Stefano ___

Re: [FYI] {master} maint: assume 'test -x' is portable

Hi Eric, thanks for the quick feedback! On 02/24/2012 12:25 AM, Eric Blake wrote: > On 02/23/2012 04:10 PM, Stefano Lattarini wrote: >> On 02/23/2012 11:49 PM, Harlan Stenn wrote: >>> Eric wrote: >>>> The autoconf manual still recommends: >>>> >>&

Re: Releasing autoconf 2.69?

On 02/24/2012 12:22 AM, Eric Blake wrote: > On 02/22/2012 01:29 PM, Stefano Lattarini wrote: >> Hello autoconfers. >> >> What would you think about the suggestion of rolling out a new autoconf >> release in the next week or so? I'd like to see this happen for a

Re: [FYI] {master} maint: assume 'test -x' is portable

On 02/23/2012 11:49 PM, Harlan Stenn wrote: > Eric wrote: >> The autoconf manual still recommends: >> >> Do not use @samp{test -x}, because 4.3BSD does not >> have it. >> >> Is this still an issue? Or should we be updating the autoconf manual? > > I remember this biting me within the last ~4 year

Re: [FYI] {master} maint: assume 'test -x' is portable

patch to the Autoconf manual: > > [SNIP] > .. I was preparing a patch about this already, that also took care of removing the workaround for missing "test -x" in M4SH. Autoconfers, WDYT? Thanks, Stefano >From c5a8a69e15ad16b81031882334724df0a8456134 Mon Sep 17 00:00:00 2001 Messa

Releasing autoconf 2.69?

Hello autoconfers. What would you think about the suggestion of rolling out a new autoconf release in the next week or so? I'd like to see this happen for at least the following reasons: * Automake's own configure.ac (in master) needs the commit bd962acf "fortran: define $GFC to "yes" if $FC i

Re: bug#10555: automake: wrong use of F77FLAGS instead of FFLAGS?

On 01/19/2012 02:45 PM, Stefano Lattarini wrote: > > [SNIP] > > So, to all autoconfers: do you happen to know any reason for which Automake > should use F77FLAGS? If not, I'll assume that is due to a typo or clerical > mistake, and fix it (in 48 hours or so). > The attac

automake: wrong use of F77FLAGS instead of FFLAGS?

Severity: minor thanks In the Automake repository, I'm seeing this: $ git grep F77FLAGS lib/Automake/Variable.pm: F77FLAGS => 'AC_PROG_F77', $ grep -C 10 F77FLAGS lib/Automake/Variable.pm # Macros shipped with Autoconf. my %_ac_macro_for_var = ( ALLOCA => 'AC_FUNC_ALLOCA',

[RFC] The documentation of general portability problems (make, shell, etc) should be in a separate manual

Hello autoconfers. Recently, various improvements and extensions have been committed to the section of the Autoconf manual dealing with Shell portability problems ("Shellology"). Unfortunately, these improvements don't yet appear in the version of the manual available on the web. That's not easi

Re: simple autoconf question

Hi Nick and Eric. On 12/20/2011 09:49 PM, Nick Bowler wrote: > On 2011-12-20 15:35 -0500, Eric Gorr wrote: >> What appears to work is the following... >> >> aclocal -I /usr/local/share/aclocal >> autoconf >> >> What I am not sure of is how to confirm just what directories will be >> search

Re: Creating jar file using autotools

On Wednesday 23 November 2011, Peter Fodrek wrote: > Dear autotools experts, > > I am stranger in builtools like autotols. My practice in Unix based C and > Java > programming using manually created Makefiles lasts 15 years. > > I am able to produce both ELF binaries (from C source code and j

Re: autoconf fails if env var U set

[Me going through oldish backlogs ...] On Thursday 14 April 2011, Paul Eggert wrote: > On 04/13/2011 11:02 AM, Tom Lane wrote: > > If the intended use is only for ansi2knr, I'd even argue that it > > should be off by default ... how many people care about ansi2knr > > anymore? > > Nobody. It wou

Re: Automake options and Libtool

[adding automake list in CC:] Hi Cédric. Please note that questions about automake should be sent to the automake list, not to the autoconf one. Thanks. On Monday 26 September 2011, GAVA Cédric wrote: > Dear all > > I am trying to pass -Wall option to AM_AUTOMAKE : > I guess you mean AM_INIT_A

Re: [PATCH] docs: other issues with parallel BSD make

On Thursday 18 August 2011, Eric Blake wrote: > On 08/18/2011 12:51 PM, Stefano Lattarini wrote: > > OK, given your considerations, I've updated my patch with the attached > > squash-in. The amended patch is attached too. Let me know if it is > > good to apply now. >

Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

On Tuesday 16 August 2011, Bob Friesenhahn wrote: > On Tue, 16 Aug 2011, Stefano Lattarini wrote: > >> > >> What is useful information today may become 'lore' in a few years so > >> it would be good to add additional data so that the reader (and > >&g

Re: [PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

Hi Bob. On Tuesday 16 August 2011, Bob Friesenhahn wrote: > On Tue, 16 Aug 2011, Stefano Lattarini wrote: > >>> > >> I'll have a "draft patch" read soonish. There is ample room for > >> improvements, > >> but I'll post it here anyway

[PATCH] docs: other issues with parallel BSD make (was: Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness)

[dropping bug-automake, adding autoconf-patches] References: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9245> <http://www.freebsd.org/cgi/query-pr.cgi?pr=159730> On Tuesday 16 August 2011, Stefano Lattarini wrote: > Hi Eric. > > On Tuesday 16 August 2011, Eric Blak

Re: bug#9245: FreeBSD make in concurrent mode report spurious success in automake-generated tests harness

Hi Eric. On Tuesday 16 August 2011, Eric Blake wrote: > On 08/16/2011 10:04 AM, Stefano Lattarini wrote: > > The "proper fix" is even easier BTW: just use "$$exit || exit 1" instead. > > > > The updated patch should now work (and I've tested it prope

Re: Missing INSTALL file

On Monday 20 June 2011, Eric Blake wrote: > On 06/20/2011 12:45 PM, David Doria wrote: > > I cloned autoconf with git clone git://git.sv.gnu.org/autoconf > > in the README is says "see INSTALL", but I don't see an INSTALL file? > > The README file is intended for those users building autoconf from

Re: bug#8599: upc (Unified Parallel C) support in automake (was: Re: AM_PROG_UPC)

On Monday 02 May 2011, Justin wrote: > Hi Stefano > Hi Justin, sorry for the delay. > On 4/30/11 1:10 PM, "Stefano Lattarini" > wrote: > > >[adding automake and bug-automake lists] > >[follow-ups might drop autoconf list IMHO] > >[Reference: >

upc (Unified Parallel C) support in automake (was: Re: AM_PROG_UPC)

[adding automake and bug-automake lists] [follow-ups might drop autoconf list IMHO] [Reference: ] Hello Justin and Ralf, and sorry for the delay. On Saturday 30 April 2011, Justin wrote: > On 4/29/11 8:57 PM, "Ralf Corsepius" wro

Re: Multiple subdirectories with non-similar configure needs

Hello autoconfers. Just my 2 cents about the issue ... On Tuesday 29 March 2011, NightStrike wrote: > On Tue, Mar 29, 2011 at 2:35 AM, Ralf Wildenhues > wrote: > > Hello Jim, > > > > * Jim Galarowicz wrote on Mon, Mar 28, 2011 at 09:08:02PM CEST: > >> I was wondering if anyone can point me to a

Re: What shells fail to work if comparing with "" ?

On Thursday 10 February 2011, Dr David wrote: > I know its considered bad practice to check for an empty string with > something like: > > if [ "$STR" = "" ] ; then > > but what shells do actually break with this, and under what conditions? > Solaris 10 /bin/sh breaks with [ "$var" != "" ] for s

Re: Macro to add more compiler warnings

Hello Javier. On Sunday 26 December 2010, Javier Jardón wrote: > Hello, > > currently in GNOME we use a custom macro to add more compiler warnings > to the build [1] > I wonder if there is a "upstream" macro to do the same. > You might be interested in the gnulib modules `warnings' and `manywarni

Re: [PATCH] Trace macros for aclocal options, deprecate ACLOCAL_AMFLAGS.

Hi Eric, Ralf. Sorry for the late answer, but I'm experiencing some hardware problems :-( Future answers (for some time at least) might be late for the same reason. On Tuesday 12 October 2010, Ralf Wildenhues wrote: > Hi Eric, > > * Eric Blake wrote on Mon, Oct 11, 2010 at 05:59:39PM CEST: > > I

Re: [PATCH] {msvc} Regenerate with autoconf 2.67

On Wednesday 15 September 2010, Eric Blake wrote: > On 09/15/2010 09:34 AM, Stefano Lattarini wrote: > >>>> - [ "$LINENO" AS_MESSAGE_LOG_FD])]) > >>>> + [ "$LINENO" AS_MESSAGE_LOG_FD ])]) > >>> > >>> How nice of Deb

Re: Bug in solaris 10 /bin/ksh w.r.t. test -z ")"

Hi Eric. On Tuesday 07 September 2010, Eric Blake wrote: > Therefore, > > > $ /bin/ksh -c 'test -z ")"; echo $?' # ready to laugh or cry? > > 0 > > this is yet another case of @var{string} that looks like an > operator, and yet another reason that you should ALWAYS use test > x"$val" = x rat

Bug in solaris 10 /bin/ksh w.r.t. test -z ")"

Hello autoconfers. Is anyone aware of this ridicoulous bug of Solaris 10 /bin/ksh? $ uname -a SunOS ... 5.10 Generic_141445-09 i86pc i386 i86pc $ strings /bin/ksh | grep -i version @(#)Version M-11/16/88i $ /bin/ksh -c 'test -z ")"; echo $?' # ready to laugh or cry? 0 $ /bin/sh -c 'test -z

Re: Nesting m4 macros

[adding autoconf@gnu.org and autom...@gnu.org] On Monday 06 September 2010, Ralf Wildenhues wrote: > > > > Have you read any tutorial about the autotools? If not, I > > > > suggest this: , > > > > which I find it very clear, and which helped me a lot

Re: Nesting m4 macros

On Monday 06 September 2010, Matthias Wichtlhuber wrote: > Hi, > > first let me thank you for your answer. > > > It seems to me that you are *greatly* misunderstanding how > > autoconf works. Have you read any tutorial about the autotools? > > If not, I suggest > > this:

Re: Nesting m4 macros

On Monday 06 September 2010, Matthias Wichtlhuber wrote: > Hi list, Hello Matthias. > this is my first post here, so I hope this is the right list Yes, it is. > and I am not violating the netiquette. > > I'm a complete autoconf newbie. For a small project I want to test, > whether the cuda NVCC

Re: wikipedia

On Saturday 21 August 2010, Ralf Wildenhues wrote: > Apologies for the slightly off-topic message, but the German > wikipedia entry for autotools contains a number of inaccuracies > and bias against it. FWIW, this is true also for the English wikipedia entry for autoconf (but *not* for the automa

${var-$default} vs. ${var=$default} (was: Re: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.)

[Removing automake-patches from CC] At Tuesday 27 July 2010, Eric Blake wrote: > On 07/27/2010 03:37 PM, Stefano Lattarini wrote: > >>> I'm used to this variant, with less typing: > >>> : ${AUTOCONF=autoconf} > >>> > >>> But your way work

Re: [PATCHES] Bootstrap: Allow user overriding of $AUTOCONF and $PERL.

Hi Eric. At Tuesday 27 July 2010, Eric Blake wrote: > On 07/27/2010 03:08 PM, Eric Blake wrote: > > On 07/27/2010 02:58 PM, Stefano Lattarini wrote: > >> +# Let user choose which version of autoconf to use. > >> +AUTOCONF=${AUTOCONF-autoconf} > >> + > >

Re: Diffing the results of conifgure

At Sunday 25 July 2010, Philip Prindeville wrote: > Hi. > > We're passing a lot of information into configure manually because > a lot of packages didn't used to handle cross-compilation > correctly, but lately those packages have been getting better. > > We'd like to start to peel away options

Re: m4 and autoconf problem on mac os x

At Wednesday 02 June 2010, Eric Blake wrote: > On 06/02/2010 03:25 PM, Stefano Lattarini wrote: > > Souldn't the printf("%s", $1) already taking care of the newline > > removal? > > Yes, but sed adds it back in. > I wasn't aware of this sed &quo

Re: m4 and autoconf problem on mac os x

Hello Raphael. At Wednesday 02 June 2010, "Raphael 'kena' Poss" wrote: > > m4_define([v_rev], m4_esyscmd([(svnversion . | grep -v exported || echo 0) > > | awk -F : '{printf("%s", $1);}' | tr 'A-z' ' ' | sed 's/ //g'])) > > you probably want to add > > | tr -d '\n' > > to that command lin

Re: m4 and autoconf problem on mac os x

Hello Vincent. Your snippet works correctly on my system (debian unstalbe, m4 1.4.13, autoconf 2.65). Which version of m4 do you have? What happens if you change the definition of `v_rev' to: m4_define([v_rev], m4_esyscmd([(svnversion . | grep -v exported || echo 0) | awk -F : '{printf("%s",

Re: Reusing the product of AC_LANG_PROGRAM().

At Tuesday 25 May 2010, Stefano Lattarini wrote: > At Tuesday 25 May 2010, Václav Haisman wrote: > > Hi. > > > > Is it possible to reuse whatever AC_LANG_PROGRAM() produces? > > I'm not an expert about this macro. but I'd do something like this: >

Re: Reusing the product of AC_LANG_PROGRAM().

At Tuesday 25 May 2010, Václav Haisman wrote: > Hi. > > Is it possible to reuse whatever AC_LANG_PROGRAM() produces? I'm not an expert about this macro. but I'd do something like this: m4_define([MY_PROLOGUE], [whatever]) m4_define([MY_BODY], [whatever2]) m4_define([MY_PROGRAM], [AC_LANG_P

Re: configure.ac parameter

At Tuesday 25 May 2010, Alex Farber wrote: > ./configure WX_CPP="compiler flags..." WX_LIBS="linker flags..." > > This doesn't work, because AC_SUBST is done when configure script > is generated, and not when it is executed. No, this doesn't work because you are setting the WX_CPP and WX_LIBS s

Re: Best practices for autotools

At Monday 03 May 2010, Lukas Kaser wrote: > Dear List, > > since some weeks I'm working with autotools and I am wondering if > some experienced users/developers wrote about best practices with > this tools. Some guideline through the whole process up to packing > could help me understanding in wh

Re: link and run a (fortran) program redirecting its stdout/stderr

At Wednesday 14 October 2009, Ralf Wildenhues wrote: > 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. Oh. This is exactly what I need. Thank you very much! Maybe the autoconf documentation might be cl

Re: link and run a (fortran) program redirecting its stdout/stderr

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. > >

Re: link and run a (fortran) program redirecting its stdout/stderr

At Tuesday 13 October 2009, Ralf Wildenhues 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&#x

link and run a (fortran) program redirecting its stdout/stderr

Hello. 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). I thought at first to