bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4


From: Mike Miller
Subject: bug#31347: AM_PROG_CC_C_O is disabled by gnulib std-gnu11.m4
Date: Wed, 2 May 2018 15:56:01 -0700
User-agent: Mutt/1.9.4 (2018-02-28)

Hi,

In GNU Octave, we are embracing a lot of C++11, and so we are using the
gnulib std-gnu11.m4 drop-in to ensure that the compiler conforms to the
latest standards. I think several other GNU projects also use this file.

The std-gnu11.m4 file defines AC_PROG_CC and AC_PROG_CXX replacements,
which I think are backported from Autoconf git.

In a trivial project, for example

    AC_INIT([test], [0])
    AM_INIT_AUTOMAKE([1.14 foreign])
    AC_PROG_CC
    AC_CONFIG_FILES([Makefile])
    AC_OUTPUT

the AM_PROG_CC_C_O feature test is automatically called, as expected and
described in the Automake 1.14 NEWS.

With std-gnu11.m4 added to this project, however, the AM_PROG_CC_C_O
macro is no longer called, either automatically or manually. The
intention of Automake to ensure that this test is always done is
defeated simply by including this file.

If a call to the real macro

    _AM_PROG_CC_C_O

is added after AC_PROG_CC, then the feature test is restored.

I know enough m4 to get by, but I suspect this has to do with the order
of inclusion, and that Automake redefines AC_PROG_CC to call its own
_AM_PROG_CC_C_O, which is later clobbered by the inclusion of
std-gnu11.m4.

Is there anything Automake can do to ensure that AM_PROG_CC_C_O is
called even if AC_PROG_CC is redefined locally?

Even if you judge this not to be an Automake bug, I wanted to bring this
to your attention, since the std-gnu11.m4 file is the recommended way to
rely on modern language standards support at the moment.

Thanks,

-- 
mike

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]