add_definitions: Surprising behaviour with string variables starting with defines like -DFOO=42
This touches closely on things discussed in #18438 (closed).
If adding defines with add_definitions()
stemming from a variable, containing more than one define, e.g. like this, things work out mostly as expected:
set(DEFS "-DBAR -DFOO=42")
add_definitions(${DEFS})
When compiling, the compile command line contains both -DBAR
and -DFOO=42
.
However, if the variables happen to be ordered differently, starting with -DFOO=42
, it behaves significantly differently:
set(DEFS "-DFOO=42 -DBAR")
add_definitions(${DEFS})
In this case, the compile command line ends up containing one argument, -DFOO="42 -DBAR"
.
If I understand #18438 (closed) correctly, the correct thing to do would be use separate_arguments
to split the string variable into a list first, then pass it to add_definitions
- and that seems to work.
This is a systematic issue in the case of LLVM; the documentation prescribes that projects that use LLVM should be calling add_definitions(${LLVM_DEFINITIONS})
to set things up. LLVM_DEFINITIONS
is a space-separated string, appended to e.g. in add_llvm_definitions.
As changing the definition of LLVM_DEFINITIONS
might break backwards compatibility, would the correct thing to do be to change the documentation, to recommend this procedure instead:
separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS})
add_definitions(${LLVM_DEFINITIONS_LIST})
(And then follow up with updates to relevant downstreams that link against LLVM in this way.)
This crops up as compile warnings, e.g. if LLVM_DEFINITIONS
happens to start with -D_FILE_OFFSET_BITS=64
without any plain -D<var>
define preceding it:
In file included from <built-in>:414:
<command line>:2:9: warning: '_FILE_OFFSET_BITS' macro redefined [-Wmacro-redefined]
#define _FILE_OFFSET_BITS 64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
^
<command line>:1:9: note: previous definition is here
#define _FILE_OFFSET_BITS 64