Description
Description of the problem:
When listening to CppCompile and ObjcCompile (mnemonic) actions on macOS and Windows, the key environment variables DEVELOPER_DIR and SDKROOT (Apple Platforms) and INCLUDE and LIB and other essentials (Windows) are missing from the environment variables in aquery and extra actions output, despite being needed to run the action successfully.
For Apple platforms, the bazel-supplied, wrapped Xcode compiler is dependent on these environment variables, and crashes if they aren't provided. For Windows, MSVC is dependent on these variables for system headers and libraries. Those environment variables provide key information about the compilation command.
On Apple platforms, some other, less-standard variables are supplied: XCODE_VERSION_OVERRIDE, APPLE_SDK_VERSION_OVERRIDE, and APPLE_SDK_PLATFORM. On Windows...not so much.
What underlying problem are you trying to solve?
The lack of these variables significantly complicates building C++ developer tooling around Bazel.
In my case, I'm integrating Bazel with clangd autocomplete in a wide variety of editors, to make development using Bazel more fun. We're linked to from the bazel docs :)
But I'd imagine this would also be useful for Kythe--the complication databases it generates would be incomplete without this, and they use action_listeners/extra_action, while we use aquery. As above, the problem exists in both.
The workaround I'm currently using on macOS using is to go direct to the system, re-inferring SDKROOT and DEVELOPER_DIR from the system Xcode commands. On Windows, I inspect the top level cc_toolchain. While these generally work, they'll miss any configuration the user does in the build graph.
More generally, it seems odd that those key variables are missing for the core cc rules. It feels like they'd be the primary purpose of being able to query the environment of C++ actions. It feels like there might be something even more general broken here.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Just run bazel aquery "mnemonic('(Objc|Cpp)Compile',//...)" on a cc_library on macOS or Windows and look at the (lack of) those environment variables.
Reproing the extra action issue is more involved, and probably is just another manifestation of the same underlying problem. But I think the fastest way to do that would be to grab Kythe's implementation of an extractor (https://github.com/kythe/kythe/blob/master/kythe/cxx/extractor/README.md) and examine the extra_actions_base_proto.