Discussion:
Detect Autoconf run in preprocessor?
Jeffrey Walton
2016-07-15 18:06:41 UTC
Permalink
We are trying to find a solution for
http://lists.gnu.org/archive/html/autoconf/2016-07/msg00003.html.

We are contemplating detecting an Autoconf run in the preprocessor,
and then (if its Autoconf) disabling the test that triggers the
'#error`.

Is there a preprocessor macro defined by Autotools to detect when
software is being configured by the tool? My apologies for asking; I
cannot simply run `g++ -dM -E - </dev/null` because it will lack
Autoconf specific defines.

Thanks in advance.
Jeffrey Walton
2016-07-15 18:47:40 UTC
Permalink
On Fri, Jul 15, 2016 at 2:35 PM, Bob Friesenhahn
Post by Jeffrey Walton
Is there a preprocessor macro defined by Autotools to detect when
software is being configured by the tool? My apologies for asking; I
cannot simply run `g++ -dM -E - </dev/null` because it will lack
Autoconf specific defines.
Everything that Autoconf defines should be visible in the generated
config.log file. The source for each test case is included.
Thanks. I'll have to ask the person for it.

But getting back to Autoconf defines, is there a preprocessor define
that Autoconf uses to identify itself?

Jeff
Eric Blake
2016-07-15 18:56:19 UTC
Permalink
Post by Jeffrey Walton
On Fri, Jul 15, 2016 at 2:35 PM, Bob Friesenhahn
Post by Jeffrey Walton
Is there a preprocessor macro defined by Autotools to detect when
software is being configured by the tool? My apologies for asking; I
cannot simply run `g++ -dM -E - </dev/null` because it will lack
Autoconf specific defines.
Everything that Autoconf defines should be visible in the generated
config.log file. The source for each test case is included.
Thanks. I'll have to ask the person for it.
But getting back to Autoconf defines, is there a preprocessor define
that Autoconf uses to identify itself?
Autoconf does not define anything specific. You can write an early
AC_DEFINE in your configure.ac to trigger a specific witness used in all
subsequent probes, but that's a per-package solution.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Jeffrey Walton
2016-07-15 19:00:24 UTC
Permalink
Post by Eric Blake
Post by Jeffrey Walton
On Fri, Jul 15, 2016 at 2:35 PM, Bob Friesenhahn
Post by Jeffrey Walton
Is there a preprocessor macro defined by Autotools to detect when
software is being configured by the tool? My apologies for asking; I
cannot simply run `g++ -dM -E - </dev/null` because it will lack
Autoconf specific defines.
Everything that Autoconf defines should be visible in the generated
config.log file. The source for each test case is included.
Thanks. I'll have to ask the person for it.
But getting back to Autoconf defines, is there a preprocessor define
that Autoconf uses to identify itself?
Autoconf does not define anything specific. You can write an early
AC_DEFINE in your configure.ac to trigger a specific witness used in all
subsequent probes, but that's a per-package solution.
Perfect, thanks.

Can the Autoconf folks recommend a name for the define? Maybe
something like GNU_AUTOCONF or similar?

The reason I ask: whatever name is recommended, I'm going to
re-recommend it to ensure consistency and to avoid 1-off solutions.
I'm also going to cite this thread as authority to use it in a
remediation.

Jeff
Jeffrey Walton
2016-07-15 19:17:59 UTC
Permalink
Post by Jeffrey Walton
Post by Eric Blake
Autoconf does not define anything specific. You can write an early
AC_DEFINE in your configure.ac to trigger a specific witness used in all
subsequent probes, but that's a per-package solution.
Perfect, thanks.
Can the Autoconf folks recommend a name for the define? Maybe
something like GNU_AUTOCONF or similar?
The point of autoconf is to probe what your system behaves like when
autoconf is not running. If you are writing headers that specifically
behave differently during configure than they do in normal usage, that
goes contrary to the goal of autoconf. I don't quite know what problem
you are up against, but the best autoconf tests are the ones written as
close to normal usage as possible, not ones that specifically try to
circumvent normality.
OK, thanks.

I fear my Autotools ignorance is hindering efforts to get this fixed.
I'm going to ask Pablo to work with you guys on a solution.

Jeff

Loading...