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

View: New views
7 Messages — Rating Filter:   Alert me  

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

by Eric Blake :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Stefano Lattarini on 10/14/2009 3:52 AM:
>> 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 clearer on this point.

Good idea.  Done:

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----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/

iEYEARECAAYFAkrnqjgACgkQ84KuGfSFAYCE+wCgu0R4u3CID1hUvtmkSfrHehgs
+5kAoICf/dMiFz6Xz/BVfGoZAVLoWrEk
=GF3p
-----END PGP SIGNATURE-----

From a7ae50526b7a526b9f297288dc5a5adeb30cf544 Mon Sep 17 00:00:00 2001
From: Eric Blake <ebb9@...>
Date: Tue, 27 Oct 2009 20:14:14 -0600
Subject: [PATCH] Mention another feature of AC_RUN_IFELSE.

* doc/autoconf.texi (Runtime) <AC_RUN_IFELSE>: Mention that
compiled test program still exists during if-true branch.

Signed-off-by: Eric Blake <ebb9@...>
---
 ChangeLog         |    7 +++++++
 doc/autoconf.texi |    2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4f93ee3..95808ed 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-10-27  Eric Blake  <ebb9@...>
+
+ Mention another feature of AC_RUN_IFELSE.
+ * doc/autoconf.texi (Runtime) <AC_RUN_IFELSE>: Mention that
+ compiled test program still exists during if-true branch.
+ Reported by Stefano Lattarini, suggestion by Ralf Wildenhues.
+
 2009-10-26  Paolo Bonzini  <bonzini@...>

  Pass Autom4te path down to programs that autoreconf invokes.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index db8c88e..a713a06 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8952,6 +8952,8 @@ Runtime
 The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
 @code{LDFLAGS} and @code{LIBS} are used for linking, in addition to the
 compilation flags of the current language (@pxref{Language Choice}).
+Additionally, @var{action-if-true} can run @command{./conftest$EXEEXT}
+for further testing.

 If the compiler being used does not produce executables that run on the
 system where @command{configure} is being run, then the test program is
--
1.6.5.rc1


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

by Ralf Wildenhues :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

* Eric Blake wrote on Wed, Oct 28, 2009 at 03:19:37AM CET:
> According to Stefano Lattarini on 10/14/2009 3:52 AM:
> >> 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 clearer on this point.
>
> Good idea.  Done:

Should we also document that the ACTION-IF-TRUE part of
AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
run) and that of AC_COMPILE_IFELSE allows compiled objects to be
inspected?  And add testsuite exposure to each?

/me tries to remember what the difference between $OBJEXT and
$ac_objext, and between $EXEEXT and $ac_ext was again ...

Thanks,
Ralf

>  The @var{input} can be made by @code{AC_LANG_PROGRAM} and friends.
>  @code{LDFLAGS} and @code{LIBS} are used for linking, in addition to the
>  compilation flags of the current language (@pxref{Language Choice}).
> +Additionally, @var{action-if-true} can run @command{./conftest$EXEEXT}
> +for further testing.



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

by Eric Blake :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 10/30/2009 12:31 AM:
> Should we also document that the ACTION-IF-TRUE part of
> AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
> run) and that of AC_COMPILE_IFELSE allows compiled objects to be
> inspected?

Hmm, those aren't done as often (about all you can do is run nm on it;
that seems like something libtool might want to do, but who else does it
to be worth documenting it?).

>  And add testsuite exposure to each?

I won't turn down help on that front.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----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/

iEYEARECAAYFAkrq1UgACgkQ84KuGfSFAYDIvQCbB0yOt2x0AON/s3E/ww0FmoMg
wEYAoL72qgdP1iZKRH0UIZWAqCp7LcMk
=R6lW
-----END PGP SIGNATURE-----



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

by Paolo Bonzini-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 10/30/2009 01:00 PM, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Ralf Wildenhues on 10/30/2009 12:31 AM:
>> Should we also document that the ACTION-IF-TRUE part of
>> AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
>> run) and that of AC_COMPILE_IFELSE allows compiled objects to be
>> inspected?
>
> Hmm, those aren't done as often (about all you can do is run nm on it;
> that seems like something libtool might want to do, but who else does it
> to be worth documenting it?).

For AC_LINK_IFELSE you could run the program if not cross-compiling.
That seems better than the AC_TRY_RUN(ac_link) that is usually done.

Paolo




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

by Ralf Wildenhues :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

* Paolo Bonzini wrote on Fri, Oct 30, 2009 at 08:36:34PM CET:

> On 10/30/2009 01:00 PM, Eric Blake wrote:
> >According to Ralf Wildenhues on 10/30/2009 12:31 AM:
> >>Should we also document that the ACTION-IF-TRUE part of
> >>AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
> >>run) and that of AC_COMPILE_IFELSE allows compiled objects to be
> >>inspected?
> >
> >Hmm, those aren't done as often (about all you can do is run nm on it;
> >that seems like something libtool might want to do, but who else does it
> >to be worth documenting it?).
>
> For AC_LINK_IFELSE you could run the program if not cross-compiling.

That also assumes that the runtime linker can find all libraries the
link editor used.  We shouldn't pretend that Autoconf takes care of
this.

> That seems better than the AC_TRY_RUN(ac_link) that is usually done.

True; that should be fixed in Libtool at least.

Thanks,
Ralf



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

by Paolo Bonzini-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


>> >  For AC_LINK_IFELSE you could run the program if not cross-compiling.
>
> That also assumes that the runtime linker can find all libraries the
> link editor used.  We shouldn't pretend that Autoconf takes care of
> this.

No worse than AC_RUN_IFELSE, though. :-)

Paolo



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

by Ralf Wildenhues :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

* Eric Blake wrote on Fri, Oct 30, 2009 at 01:00:08PM CET:
> According to Ralf Wildenhues on 10/30/2009 12:31 AM:
> > Should we also document that the ACTION-IF-TRUE part of
> > AC_LINK_IFELSE allows linked programs to be inspected (not necessarily
> > run) and that of AC_COMPILE_IFELSE allows compiled objects to be
> > inspected?
>
> Hmm, those aren't done as often (about all you can do is run nm on it;
> that seems like something libtool might want to do, but who else does it
> to be worth documenting it?).

You can rename it, compile another object and link both together.
There are cases where testing a program made up of more than one object
is of interest.

Even for libtool it would be nice to have certainty.  But you're right,
this isn't that urgent or important.

> >  And add testsuite exposure to each?
>
> I won't turn down help on that front.

Not even needed: I merely didn't find
  tests/compile.at:Order of user actions and cleanup

until now.  Gee, I really should try to hack up that coverage map ...

Cheers,
Ralf