CODEWITHSUNDEEP
cautotoolsautoconf
Mostafa Barmshory
Mostafa Barmshory

Reputation: 2039

Adding a dynamic symbol name not work with AC_DEFINE_UNQUOTED from configure.ac

There is a macro to add a new symbol into the resulting config.h file from a configuration file. This allows you to check the system and enable options in C/C++ applications. There are two types of macros: adding a dynamic symbol and a fixed symbol. By using AC_DEFINE_UNQUOTED, which is a macro to add a dynamic symbol, it is possible to set a symbol where the name or value is from a variable.

Here is my simple configure.ac file

name="test"
AC_DEFINE_UNQUOTED([USE_${name}], [1], [Enable test usage])

I expecte that USE_test be added into config.h as C/C++ definistion. However, the difinistion does not exist in the result config.h file.

By running Autotools there is the following line in configure.status:

D["USE_test"]=" 1"

This means Autotools will search the config.h.in to replace the USE_test with the new value.

But the generated config.h.in file does not contain the following definition:

#define Use_test 1

So Autoheader does not run correctly?! And it is not possible to add a variable text as a symbol to config.h?!

Where is the problem or is it possible to add a symbol with a variable name by configure.ac?

Upvotes: 1

Views: 446

Answers (1)

John Bollinger
John Bollinger

Reputation: 180161

But the final config.h file does not contain the following definition [...] config.h.in is generated dynamically and it does not contain the definition too.

The latter is actually the key issue. When you use AC_CONFIG_HEADERS to request that definitions be recorded in a header file instead of being expressed via compiler command-line options, Autoconf handles it by processing one or more header templates, such as config.h.in, to produce the resulting header(s). The autoconf command does not produce these templates itself, however. You can write them by hand if you wish, but a separate program, autoheader, is available to perform this job, and autoreconf (not autoconf) automatically runs autoheader to generate a template for the first header named in the first AC_CONFIG_HEADERS call.

The behavior you describe is a longtime known issue (not accounted a bug, per se), which you can find discussed in the archives of the bug-autoconf mailing list. The resolution was a documentation change, whose result you can still see in the section of the Autoconf manual that discusses Autoheader:

In order to do its job, autoheader needs you to document all of the symbols that you might use. Typically this is done via an AC_DEFINE or AC_DEFINE_UNQUOTED call whose first argument is a literal symbol and whose third argument describes the symbol (see Defining Symbols).

(Emphasis added.)

This indeed seems to be the technically appropriate place for those details. That is, AC_DEFINE_UNQUOTED does behave as advertised, as can be seen by disabling AC_CONFIG_HEADERS (a viable workaround under many circumstances), or by employing one of the alternatives the docs go on to suggest:

you can use AH_TEMPLATE (see Autoheader Macros), or you can supply a suitable input file for a subsequent configuration header file. Symbols defined by Autoconf's builtin tests are already documented properly; you need to document only those that you define yourself.

If you were to argue that it would have been nice for that issue to be mentioned in the AC_DEFINE_UNQUOTED docs, too, then I would fully agree with you. But I do also think that the situation is considerably different now than when the doc change was first put in, on account of the introduction and rise to prevalence of autoreconf, which hides the involvement of autoheader from most users.

In any case, I'll ignore the "supply your own template" option, which is a bit fraught, and focus on AH_TEMPLATE. To use it to support the particular case presented in the question, one would add something along these lines to configure.ac:

AH_TEMPLATE([USE_test], [Define to 1 to use test])

Perhaps you ask "What's the point then? I might as well use a regular AC_DEFINE." That's a good question, to which you should indeed give careful consideration. Note well that there is no point to defining arbitrary preprocessor macros, as only those corresponding to symbols appearing in one or more of your sources will ever be expanded. That does not necessarily make configure-time macro name generation useless, but it does mean that when maintaining configure.ac, you can and should have a complete list of all the generated macro names that need to be supported. In that case, it is indeed plausible that you might write appropriate AH_TEMPLATE invocations for all the needed cases. Under most circumstances, however, going straight to (conditional) AC_DEFINEs for each symbol is probably a better choice.

Upvotes: 2

Related Questions