How do I set defines included through the toolchain?

[anthonymahshigian]

Hello! Some macros such as UINT_MAX are defined in files through the toolchain. One example of this is clang's limits.h https://clang.llvm.org/doxygen/limits_8h_source.html

How can I make DWYU aware of these? Is it possible for it to be aware of the toolchain at all? If not, a suboptimal solution could be to do something like what is done for extra_ignore_include_paths where we hardcode a list of includes available. FWIW I've been hardcoding a subset of the defines I care about via a patch and it's worked fine for my use case, but if there is a better way to do this that would be ideal. The reason defines may matter is they affect which includes are used.

Thanks!

[martis42]

It is an open TODO to incorporate the Bazel C++ toolchain as source for which headers are available to the targets.

It is hard to come with a generic solution to all potential cases involving defines without hooking into the compiler itself (which this project actively decided against for better or worse). I might introduce an interface to hard code whatever defines a user wants to be always set 🤔 Can't promise anything concrete yet though.

[martis42]

@anthonymahshigian
Thinking about this again, I believe --cxxopt should be the solution for hard coding defines without having to patch DWYU. DWYU creates the list of known defines by analyzing the command line, which would be created for the compiling command. Thus, defines provided via --cxxopt=... will be picked up by DWYU.

I imaging you would create a config for executing DWYU in your .bazelrc file. Besides hiding the aspect invocation boilerplate, this config could also define via --cxxopt=-DFOO=42 the defines you want to be universally set.
This should work with DWYU >= 0.0.11. While looking into this I realized that while picking up --cxxopt values was always intended behavior, it was not tested until now, which I now fixed to prevent this breaking by accident #327.

For now I don't intend to add a new feature to the DWYU aspect for hard coding a list of defines, as this is already possible today with existing features and standard Bazel.

---

That much said, ideally DWYU would be able to give pcpp the include paths to the toolchain headers, so the preprocessor can properly detect defines from those without manual information duplication by the user. This feature is planned and tracked in #63. But right now I have no estimate when I will be able to work on this.

---

For now I will keep this issue open in case further discussion is required and this solution does not allow you to hard code defines more elegantly until a full toolchain support is done.