# C Preprocessor Dependency Scanning for Custom Languages
**URL:** https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519
**Category:** Development
**Created:** [January 17, 2020, 9:19pm UTC](https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519 "2020-01-17T21:19:02Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@sennis](https://discourse.cmake.org/u/sennis)
#### Post date: [January 17, 2020, 9:19pm UTC](https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519/1 "2020-01-17T21:19:03Z")
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](https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmLocalUnixMakefileGenerator3.cxx), it cannot scan the source files for included files to be added as dependencies.
```auto
if (lang == "C" || lang == "CXX" || lang == "RC" || lang == "ASM" ||
lang == "CUDA") {
// TODO: Handle RC (resource files) dependencies correctly.
scanner = cm::make_unique(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.
```cmake
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.
---
### Author:  [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [January 17, 2020, 9:27pm UTC](https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519/2 "2020-01-17T21:27:01Z")
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.
---
### Author:  [@sennis](https://discourse.cmake.org/u/sennis)
#### Post date: [January 17, 2020, 10:25pm UTC](https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519/3 "2020-01-17T22:25:06Z")
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.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [January 20, 2020, 3:59pm UTC](https://discourse.cmake.org/t/c-preprocessor-dependency-scanning-for-custom-languages/519/4 "2020-01-20T15:59:29Z")
In principle it would be reasonable to have a per-language variable that can be set by `Modules/CMakeInformation.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”.