[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.
From: |
Stefano Lattarini |
Subject: |
Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required. |
Date: |
Sun, 13 Jan 2013 21:41:07 +0100 |
On 01/13/2013 09:01 PM, Nick Bowler wrote:
> If subdir-objects is made the default Automake behaviour, packages
> will need to add AM_PROG_CC_C_O to their configure.ac. Instead of
> that, let's just make the functionality provided by AM_PROG_CC_C_O
> mandatory for C projects, and have Automake automatically call it
> as required.
>
> This change should have no effect on packages which explicitly call
> AM_PROG_CC_C_O already.
>
> * m4/init.m4: Have AM_INIT_AUTOMAKE arrange for AM_PROG_CC_C_O to be
> called if necessary.
> ---
> m4/init.m4 | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/m4/init.m4 b/m4/init.m4
> index 7535706..6c48704 100644
> --- a/m4/init.m4
> +++ b/m4/init.m4
> @@ -109,6 +109,11 @@ AC_PROVIDE_IFELSE([AC_PROG_OBJCXX],
> [m4_define([AC_PROG_OBJCXX],
>
> m4_defn([AC_PROG_OBJCXX])[_AM_DEPENDENCIES([OBJCXX])])])dnl
> ])
> +dnl Automatically invoke AM_PROG_CC_C_O as necessary. Since AC_PROG_CC is
> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
> +dnl done later by AC_CONFIG_COMMANDS_PRE.
>
This would also have the advantage that we shouldn't worry about possible
$CC rewrites between the AC_PROG_CC and the AC_OUTPUT invocation. Your
approach might actually be not only the simplest, but also the sanest one.
That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
"-c -o" support. But that is quite orthogonal to your patch, and material
for a follow-up anyway.
Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
make AM_PROG_CC_C_O a no-op (without runtime deprecation). That way, we
could rely on the improved semantic of having the potential '$CC' rewrite
placed near the end of configure, rather than near the beginning. WDYT?
> +AC_CONFIG_COMMANDS_PRE([AC_PROVIDE_IFELSE([AC_PROG_CC],
> + [AC_LANG([C]) AM_PROG_CC_C_O])])dnl
> AC_REQUIRE([AM_SILENT_RULES])dnl
> dnl The testsuite driver may need to know about EXEEXT, so add the
> dnl 'am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen. This
Thanks,
Stefano
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, (continued)
- Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Eric Blake, 2013/01/11
- Backward-compatibility in the autotools (was: Re: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers), Stefano Lattarini, 2013/01/11
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/11
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/12
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Nick Bowler, 2013/01/13
- Re: bug#13378: [PATCH] compile: use 'compile' script when "-c -o" is used with losing compilers, Stefano Lattarini, 2013/01/13
- [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Nick Bowler, 2013/01/13
- Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.,
Stefano Lattarini <=
- Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Nick Bowler, 2013/01/13
- Re: bug#13378: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required., Stefano Lattarini, 2013/01/14
- Cleaning up AC_PROG_CC_C_O semantics (was: Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.), Stefano Lattarini, 2013/01/14
- Re: Cleaning up AC_PROG_CC_C_O semantics, Paul Eggert, 2013/01/14
- Re: Cleaning up AC_PROG_CC_C_O semantics, Stefano Lattarini, 2013/01/14
- Re: Cleaning up AC_PROG_CC_C_O semantics, Paul Eggert, 2013/01/14
- Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics, Stefano Lattarini, 2013/01/16
- Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics, Paul Eggert, 2013/01/16
- Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics, Eric Blake, 2013/01/16
- Re: bug#13378: Cleaning up AC_PROG_CC_C_O semantics, Stefano Lattarini, 2013/01/16