Help needed on how to resolve a circular dependency.

[Dale Visser]

I'm attempting to modify AC_PROG_CC to include another macro that I'm
adding as well. The problem I'm hitting is that the new macro invokes
AC_COMPILE_IF_ELSE, which ends up doing an AC_REQUIRE([AC_PROG_CC}). Of
course, then autoconf is unhappy since AC_PROG_CC is effectively calling
AC_REQUIRE on itself.

The new macro is not specific to C. It can also be run for C++ and Fortran
projects, and I'm just focusing on making it work for C first. In fact, I
am attempting to integrate AX_FLAGS_WARN_ALL into autoconf (as per a
previous thread on this list in October:
https://lists.gnu.org/archive/html/autoconf/2013-10/msg00029.html). The
integration has been successful. This next part, making it used by default,
is what I'm attempting to do now.

In hindsight, it makes perfect sense that AX_FLAGS_WARN_ALL ends up
requiring AC_PROC_CC, because it produces test runs of the compiler to
check whether specific flags are supported by the current compiler.

Everything works just fine if my configure.ac just calls my new macro, but
what I really want to do is modify things such that by default AC_PROG_CC
invokes the new macro. Does anybody have advice, general or specific to my
case, about how best to untangle autoconf circular require dependencies?

Best regards,
Dale Visser

P.S. My apologies if any of this was unclearly or imprecisely stated. Macro
processing is something I rarely touch or have to worry, about unless you
count the occasional usage of Bourne shell variables in hand-written
scripts.

[Dale Visser]

-----Original Message-----
From: "Dale Visser" <***@gmail.com>
Sent: ‎12/‎23/‎2013 2:02 PM
To: "***@gnu.org" <***@gnu.org>
Subject: Help needed on how to resolve a circular dependency.

I'm attempting to modify AC_PROG_CC to include another macro that I'm
adding as well. The problem I'm hitting is that the new macro invokes
AC_COMPILE_IF_ELSE, which ends up doing an AC_REQUIRE([AC_PROG_CC}).
Of course, then autoconf is unhappy since AC_PROG_CC is effectively
calling AC_REQUIRE on itself.

The new macro is not specific to C. It can also be run for C++ and
Fortran projects, and I'm just focusing on making it work for C first.
In fact, I am attempting to integrate AX_FLAGS_WARN_ALL into autoconf
(as per a previous thread on this list in October:
https://lists.gnu.org/archive/html/autoconf/2013-10/msg00029.html).
The integration has been successful. This next part, making it used by
default, is what I'm attempting to do now.

In hindsight, it makes perfect sense that AX_FLAGS_WARN_ALL ends up
requiring AC_PROC_CC, because it produces test runs of the compiler to
check whether specific flags are supported by the current compiler.


Everything works just fine if my configure.ac just calls my new macro,
but what I really want to do is modify things such that by default
AC_PROG_CC invokes the new macro. Does anybody have advice, general or
specific to my case, about how best to untangle autoconf circular
require dependencies?


Best regards,
Dale Visser


P.S. My apologies if any of this was unclearly or imprecisely stated.
Macro processing is something I rarely touch or have to worry, about
unless you count the occasional usage of Bourne shell variables in
hand-written scripts.

[Dale Visser]

I’ve looked at it further this morning. A possible solution I can see on my
own is dropping in the the AC_*FLAGS_WARN_ALL as replacing the old
AC_PROG_* macros, and renaming the old macros to AC_PROG_*_OLD/CLASSIC. The
AC_PROG_* macros each have their own sets of parameters (enabling
specification of an an unknown compiler, and dialect in the case of
Fortran). Because of this, it is quite possible my proposed change would
break peoples’ builds.

What is the stance in autoconf on "API-Breaking" changes like this?

From what I can see so far, it will be quite difficult to break this
circular dependency. Sure, I could provide AC_PROG_CC_WARN_ALL separate
from AC_PROG_CC, for instance, but the goal is to turn on warnings for all
projects using autoconf, and make it easy for them to dial back or turn off
the warnings with a small change to their configure.ac files.

Best regards,
Dale Visser