C Preprocessor Dependency Scanning for Custom Languages

I have been working on a project that requires 2 different compilers. I have written the language files so that the secondary compiler files can be compiled via add_executable, add_library, etc. This secondary compiler uses the C Preprocessor. However due to line 1464 of cmLocalUnixMakefileGenerator3.cxx, it cannot scan the source files for included files to be added as dependencies.

    if (lang == "C" || lang == "CXX" || lang == "RC" || lang == "ASM" ||
        lang == "CUDA") {
      // TODO: Handle RC (resource files) dependencies correctly.
      scanner = cm::make_unique<cmDependsC>(this, targetDir, lang, &validDeps);
    }

Instead of a flat language check, I would propose implementing a language variable that determines if the language uses the C Preprocessor, and scan associated files accordingly.

set(CMAKE_FOO_USES_CPP ON)

If I have fallen into any anti-patterns, I would love the feedback, but otherwise, I am checking to see if this a sane feature request.

Typically, adding support for a new language to CMake involves modifying CMake itself, both the binaries and the internal module files. This is due to the fact that different languages require different handling that can’t be expressed at the CMake language level. If we added such a variable, we would be exposing the internals of CMake in a way that we can’t change later on due to backwards compatibility issues.

What it comes down to is that we simply don’t support adding support for new languages without modifying CMake itself.

Section 11.4 of Kitware’s Mastering CMake book, named Adding a New Language, details how one would add a language without changing the CMake internals. Has Kitware changed its stance on adding languages since the publishing of Mastering CMake?

Otherwise, I am seeing that the function above would not have CMake variables from language files in scope, so my proposal doesn’t seem like the right answer, and it would take a lot more effort to implement.

In principle it would be reasonable to have a per-language variable that can be set by Modules/CMake<LANG>Information.cmake to tell the Makefile generator to scan C preprocessor dependencies for that language.

However, the Makefile generator’s builtin dependency scanner’s future is in question in general because we will need a major rewrite of the way the Makefile dependencies work to accommodate C++20 module dependencies. The result will look more like the Ninja generator does now, which depends on toolchain-generated “depfiles”.