As part of Gradle's core mechanic, the header dependency graph doesn't account for undefined macros. These are especially important in preprocessor libraries (like Boost). This doesn't mean we should necessarily support tracking of (un)defined macros, but we need to be aware that #include SOME_MACRO may mean different files depending on the macro context. At the moment, Gradle core mechanic will discover the potentially multiple definitions of SOME_MACRO, but only the first definition will be considered when resolving the include. The first definition may vary depending on previously visited headers (see the other issue). The graph may be slightly wrong because macros can be undefined, and some headers are designed to be included multiple times (see the other issue). Gradle header graph discovery is not meant to be 100% accurate, but only good enough so the task can be deemed out-of-date/up-to-date when required and cached.
One strategy we may opt for is simply resolving the include out of all the known definitions of SOME_MACRO. Gradle uses this strategy currently. If that strategy is good enough, we should document the behaviour better with examples.
As part of Gradle's core mechanic, the header dependency graph doesn't account for undefined macros. These are especially important in preprocessor libraries (like Boost). This doesn't mean we should necessarily support tracking of (un)defined macros, but we need to be aware that
#include SOME_MACROmay mean different files depending on the macro context. At the moment, Gradle core mechanic will discover the potentially multiple definitions ofSOME_MACRO, but only the first definition will be considered when resolving the include. The first definition may vary depending on previously visited headers (see the other issue). The graph may be slightly wrong because macros can be undefined, and some headers are designed to be included multiple times (see the other issue). Gradle header graph discovery is not meant to be 100% accurate, but only good enough so the task can be deemed out-of-date/up-to-date when required and cached.One strategy we may opt for is simply resolving the include out of all the known definitions of
SOME_MACRO. Gradle uses this strategy currently. If that strategy is good enough, we should document the behaviour better with examples.