[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Knowing which tool is being run, from M4
From: |
Eric Blake |
Subject: |
Re: Knowing which tool is being run, from M4 |
Date: |
Wed, 5 Aug 2020 14:51:39 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 8/5/20 2:35 PM, Zack Weinberg wrote:
This feels like a stupid question but I’ve been failing to find the answer
all day. Is there a way for M4 code (specifically in autoconf/general.m4,
if it matters) to tell which command-line tool (autoconf, autoheader, etc.)
is being run?
Nothing obvious jumps out at me. Each command-line tool calls autom4te
--language=XYZ, where the choice of language determines which other
arguments are pre-loaded. Perhaps seeing if a particular witness macro
is defined from a given language's presets is enough to deduce things,
though? For example, the 'M4sugar' language is the base of the
inheritance tree, so it is always loaded; the 'M4sh' language loads a
definition of AS_INIT from m4sh.m4f (so if that macro is not defined,
you are in m4sugar rather than m4sh); the 'Autotest' language loads
autotest.m4f on top of M4sh (so seeing if AT_INIT is defined is a good
witness); the 'Autoconf' language loads in autoconf.m4f on top of M4sh
(so seeing if AC_INIT is defined is a good witness). On the other hand,
autom4te doesn't have an 'Autoheader' language per se, but does define
'Autoheader-preselections', but that doesn't cause any extra files to be
loaded or new macros to be defined, so offhand I don't see an easy
witness to tell when autoheader is being run, and the autoheader binary
calls autom4te --language=autoconf.
It might be an interesting idea to add support for a well-documented
macro (probably at the m4sugar namespace) that can be queried to learn
the current language, and then updating autom4te or each binary that
calls autom4te to use -Dm4_language=XYZ to then make that macro be a
reliable indicator of which language flavor is being run under autom4te.
But given the difference in release cycles between autoconf and
automake, that may still not help you in the short term for learning
when automake is running things (other than seeing if AM_INIT is defined).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org