Skip to content
  • Stefano Lattarini's avatar
    34001a98
    compile: use 'compile' script when "-c -o" is used with losing compilers · 34001a98
    Stefano Lattarini authored
    Do so seen when only source files in the "current" directory are present.
    
    This commit is part of a series of related changes addressing automake
    bug#13378 (see also the plan 'PLANS/subdir-objects.txt').
    
    Before this change, Automake-generated C compilation rules mistakenly
    passed the "-c -o" options combination unconditionally (even to losing
    compiler) when the 'subdir-objects' was used but sources were only
    present in the top-level directory.  Issue spotted by Nick Bowler:
    
      <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
      <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44
    
    >
    
    We fix this by having Automake redefine AC_PROG_CC to take over the role
    of AM_PROG_CC_C_O and to require the 'compile' script unconditionally
    (albeit that will continue to be invoked only when inferior compilers
    are detected).
    
    Among other things, this means AM_PROG_CC_C_O explicitly is no longer
    required; that macro is still supported for backward-compatibility, but
    calling it is basically a no-op now.
    
    This change has some pros and some cons (obviously, we believe the former
    outweighs the latter).  Here are the most relevant ones:
    
    + Pros 1:
      Some logic in the Automake script has been simplified.
    + Pros 2:
      That simplification has automatically fixed an actual bug (see
      Nick's mails referenced above; admittedly, that was present only in
      corner-case situations, but still); the test 't/ccnoco4.sh', which
      demonstrated the bug and has been failing so far, now passes.
    + Pros 3:
      Things works more "automagically" now (no need to manually add the
      AM_PROG_CC_C_O macro to configure.ac anymore).
    
    * Cons 1:
      The 'compile' script will be required in all projects using C
      compilation; this will only be a problem for packages not using
      '--add-missing'.  However, such packages are definitely more rare
      than the ones using '--add-missing', and adjusting them will be
      trivial -- just copy the compile script over from the new Automake
      installation.
    * Cons 2:
      The copy & paste of autoconf internals hack this change has introduced
      in our "rewrite" of AC_PROG_CC is really an egregious abomination.  It
      can only be justified with the fact that we expect future versions of
      autoconf to implement the semantics we need directly in AC_PROG_CC, so
      that we'll be able to leverage that (since Automake 1.14 will require
      the latest Autoconf version released).
    
    Now, the detailed list of file-by-file changes ...
    
    * automake.in ($seen_cc_c_o): Remove this global variable.
    (scan_autoconf_traces): Don't set it, and do not trace the
    'AM_PROG_CC_C_O' m4 macro.
    (lang_c_rewrite): Remove, no longer needed.
    * doc/automake.texi: Adjust expected "autoreconf --install" output
    in the amhello example.  Remove statements about the need for the
    AM_PROG_CC_C_O macro.  Report it is obsolete now.
    * m4/init.m4: Re-write AC_PROG_CC to append checks about whether the
    C compiler supports "-c -o" together.  These checks have basically
    been ripped out (with adaptations) from the 'AC_PROG_CC_C_O' macro
    of Autoconf and ...
    * m4/minuso.m4 (AM_PROG_CC_C_O): ... this macro of ours, which has
    thus basically become a no-op.
    * t/ax/am-test-lib.sh (am_setup_testdir): Also copy the 'compile'
    script in the test directory; if we don't do so, every test using
    AC_PROG_CC should call automake with the "--add-missing" option, or
    copy the 'compile' script itself.
    * t/cond11.sh: No need to create a dummy 'compile' script: that is
    already brought in by 'am_setup_testdir()', that is automatically
    invoked when 'test-lib.sh' is sourced.
    * t/add-missing.tap: Adjust: we expect the 'compile' script to be
    required by a mere AC_PROG_CC call now.
    * t/dist-auxdir-many-subdirs.sh: Likewise.
    * t/specflg6.sh: Likewise.
    * t/subobj4.sh: Likewise.
    * t/cxx-lt-demo.sh: Likewise, and update comments to match.
    * t/distcom2.sh: Enhance a little.
    * t/dollarvar2.sh: Adjust.
    * t/extra-portability.sh: Likewise.
    * t/libobj19.sh: Likewise.
    * t/per-target-flags.sh: Likewise.
    * t/repeated-options.sh: Likewise.
    * t/subobj.sh: Likewise, and enhance a little.
    * t/ccnoco2.sh: Remove as obsolete.
    * t/list-of-tests.mk (handwritten_TESTS): Adjust.
    (XFAIL_TESTS): Remove 't/ccnoco4.sh'.
    * NEWS: Update.
    
    Signed-off-by: default avatarStefano Lattarini <stefano.lattarini@gmail.com>
    34001a98
    compile: use 'compile' script when "-c -o" is used with losing compilers
    Stefano Lattarini authored
    Do so seen when only source files in the "current" directory are present.
    
    This commit is part of a series of related changes addressing automake
    bug#13378 (see also the plan 'PLANS/subdir-objects.txt').
    
    Before this change, Automake-generated C compilation rules mistakenly
    passed the "-c -o" options combination unconditionally (even to losing
    compiler) when the 'subdir-objects' was used but sources were only
    present in the top-level directory.  Issue spotted by Nick Bowler:
    
      <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
      <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44
    
    >
    
    We fix this by having Automake redefine AC_PROG_CC to take over the role
    of AM_PROG_CC_C_O and to require the 'compile' script unconditionally
    (albeit that will continue to be invoked only when inferior compilers
    are detected).
    
    Among other things, this means AM_PROG_CC_C_O explicitly is no longer
    required; that macro is still supported for backward-compatibility, but
    calling it is basically a no-op now.
    
    This change has some pros and some cons (obviously, we believe the former
    outweighs the latter).  Here are the most relevant ones:
    
    + Pros 1:
      Some logic in the Automake script has been simplified.
    + Pros 2:
      That simplification has automatically fixed an actual bug (see
      Nick's mails referenced above; admittedly, that was present only in
      corner-case situations, but still); the test 't/ccnoco4.sh', which
      demonstrated the bug and has been failing so far, now passes.
    + Pros 3:
      Things works more "automagically" now (no need to manually add the
      AM_PROG_CC_C_O macro to configure.ac anymore).
    
    * Cons 1:
      The 'compile' script will be required in all projects using C
      compilation; this will only be a problem for packages not using
      '--add-missing'.  However, such packages are definitely more rare
      than the ones using '--add-missing', and adjusting them will be
      trivial -- just copy the compile script over from the new Automake
      installation.
    * Cons 2:
      The copy & paste of autoconf internals hack this change has introduced
      in our "rewrite" of AC_PROG_CC is really an egregious abomination.  It
      can only be justified with the fact that we expect future versions of
      autoconf to implement the semantics we need directly in AC_PROG_CC, so
      that we'll be able to leverage that (since Automake 1.14 will require
      the latest Autoconf version released).
    
    Now, the detailed list of file-by-file changes ...
    
    * automake.in ($seen_cc_c_o): Remove this global variable.
    (scan_autoconf_traces): Don't set it, and do not trace the
    'AM_PROG_CC_C_O' m4 macro.
    (lang_c_rewrite): Remove, no longer needed.
    * doc/automake.texi: Adjust expected "autoreconf --install" output
    in the amhello example.  Remove statements about the need for the
    AM_PROG_CC_C_O macro.  Report it is obsolete now.
    * m4/init.m4: Re-write AC_PROG_CC to append checks about whether the
    C compiler supports "-c -o" together.  These checks have basically
    been ripped out (with adaptations) from the 'AC_PROG_CC_C_O' macro
    of Autoconf and ...
    * m4/minuso.m4 (AM_PROG_CC_C_O): ... this macro of ours, which has
    thus basically become a no-op.
    * t/ax/am-test-lib.sh (am_setup_testdir): Also copy the 'compile'
    script in the test directory; if we don't do so, every test using
    AC_PROG_CC should call automake with the "--add-missing" option, or
    copy the 'compile' script itself.
    * t/cond11.sh: No need to create a dummy 'compile' script: that is
    already brought in by 'am_setup_testdir()', that is automatically
    invoked when 'test-lib.sh' is sourced.
    * t/add-missing.tap: Adjust: we expect the 'compile' script to be
    required by a mere AC_PROG_CC call now.
    * t/dist-auxdir-many-subdirs.sh: Likewise.
    * t/specflg6.sh: Likewise.
    * t/subobj4.sh: Likewise.
    * t/cxx-lt-demo.sh: Likewise, and update comments to match.
    * t/distcom2.sh: Enhance a little.
    * t/dollarvar2.sh: Adjust.
    * t/extra-portability.sh: Likewise.
    * t/libobj19.sh: Likewise.
    * t/per-target-flags.sh: Likewise.
    * t/repeated-options.sh: Likewise.
    * t/subobj.sh: Likewise, and enhance a little.
    * t/ccnoco2.sh: Remove as obsolete.
    * t/list-of-tests.mk (handwritten_TESTS): Adjust.
    (XFAIL_TESTS): Remove 't/ccnoco4.sh'.
    * NEWS: Update.
    
    Signed-off-by: default avatarStefano Lattarini <stefano.lattarini@gmail.com>
Loading