Would it be better to just run the C/C++ preprocessor on the file instead of building a poor man's version of the preprocessor into this task?

I've investigated what it would take to use C/C++ preprocessor:

• We can't really run it during coreclr build - it would mean that building CoreLib requires output from CoreCLR build - which is a new dependency and the infra team really doesn't like this (it would also mean that dotnet build on CoreLib would basically never work fully).
• Running CMake from CoreLib build is a possibility, but it's complex and probably slow (we already have 3 places we start native build pipeline in the runtime repo, this would introduce a new one - while we're trying hard to go down to just 1 place ideally).
• That leaves running the preprocessor directly (without CMake) from the CoreLib build. This is probably not that hard since we have scripts to find the compiler path - Windows to get cl.exe on PATH, Linux, macOS to get clang path into CC/CXX. That said it's still not exactly easy as we would be adding a new thing into the pipeline for CoreLib - the risk here is that we have to construct the compiler command line by hand - making that work on all the platforms could be time consuming.
  • This also comes with a downside - we would not run it in the same environment as within CoreCLR build, for example we would have to propagate the defines manually.

In the meantime, there's a request to add additional logic to this process to be able to specify that some of the roots should be added behind a feature switch (built-in COM support), which puts additional pressure on making this happen.

So the proposal is:

• Keep the current "hacky" solution (merge this PR and then the one in runtime)
• Define new macros for the feature switch support so that we express that in a C++ syntax - but still use the "hacky" parser for it
• File an issue to improve this in the future - documenting the knowledge from the investigation done so far.

What do you think @jkotas ?

/cc @LakshanF

Sounds good. Thank you for looking into this.

File an issue to improve this in the future

The ultimate plan would be to switch to the same plan that Mono is on: Capture the dependencies introduced by the VM side explicitly by regular DynamicDependency attributes (and probably also convert more of the VM logic to C# so that it is maintainable). This whole task can then disapper.

I filed dotnet/runtime#51991 to track this