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