Enable changing the translation unit that services a header file

[ghuser404]

When multiple targets include the same file (say public library header), they may #define different variables which will change the active part of the header.

There must be an option to view files based on a selected target. This is not only about #defines, but also include paths, etc. One target may include path with "foo.h", but the other may not include that path. So based on a selected target, it should show squiggles accordingly.

[vector-of-bool]

This use case is probably unsupportable with the current infrastructure. The compilation flags associated with a header come from the target to which that header is attached, and CMake has no to represent a file being attached to more than one target.

Instead, I would recommend a refactoring of splitting the content of the header into two or more other headers based on the content that should be defined, and having the main header pick which one to #include based on the preprocessor definitions.

[ghuser404]

I would recommend a refactoring

I can't refactor 3rd party libraries.

and having the main header pick which one to #include based on the preprocessor definitions.

It would still be cool if this main header showed correctly depending on what target is using it.

CMake has no to represent a file being attached to more than one target.

Visual Studio and QtCreator support it.

[rhymu8354]

This issue is pretty much a deal-breaker for me using the CMake Tools extension, sad to say (because otherwise I think the extension does a really good job integrating build systems with VSCode!) Unfortunately, in C it's common to use macros to vary the compilation context for the same header file depending on who is including it and/or for what reason.

A classic example is the pattern in Windows for controlling whether the entrypoint functions in a loadable module are being imported or exported:

#if COMPILING_DLL
    #define DLLEXPORT __declspec(dllexport)
#else
    #define DLLEXPORT __declspec(dllimport)
#endif

Now if there was a way to set the compilation context, even if it's just as crude as what Visual Studio does (lets you select a target when viewing a header file), I think this would solve the problem for the majority of users who run into this issue.

[ghuser404]

A classic example is the pattern in Windows for controlling whether the entrypoint functions in a loadable module are being imported or exported

Thanks for the example, this is exactly what I'm talking about.

even if it's just as crude as what Visual Studio does (lets you select a target when viewing a header file)

Crude? Do you have a better idea how it potentially could be done? As far as I know, QtCreator does it the same way.

[rhymu8354]

By "crude" I mean you can only select a target. A more fine context selection would be to pick a specific compilation unit (e.g. a single .c or .cpp file being compiled), because although it's perhaps not best practice, you could have different compile definitions given on the command line when compiling each source file. Also, each source file may include a different set of headers, or include headers in a different order, resulting in all sorts of fun problems.

[bobbrow]

Compilation unit-based context selection for headers is something cpptools should consider supporting. I think this would also solve some of the existing problems around having to "guess" which .cpp file to assign a given header to. I will copy this issue into the cpptools repo.