4 ms·

I’m not very familiar with C++ build tools which parse source code for header dependencies, but I know that C++ compilers (the preprocessor specifically) does t

by zach43 9y ago

I’m not very familiar with C++ build tools which parse source code for header dependencies, but I know that C++ compilers (the preprocessor specifically) does this. From what I know of cmake and gmake, neither of these build tools automatically parse C++ files to find dependent header files, but both require manual specification of the include directories and include paths.

mattnewport 9y ago
Build pipelines I'm familiar with typically parse the includes from a .cpp file (and potentially recursively through the included headers) and resolve the includes to actual files based on include paths specified as part of the build configuration. Sometimes this information is cached in a .dep file or by some other mechanism. This information is then used to determine what actually needs to get built by an incremental build when a header changes. The compiler is usually passed include paths to resolve includes when invoked. The build tool need to track this just to enable minimal incremental builds.
comex 9y ago
They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done by having the build tool parse C++ files. Rather, while compiling a given .cpp file, the compiler is instructed (using -MD or other variants starting with -M) to output a .d file listing all the header files it encounters as it goes, which are then treated as dependencies. The output format is a subset of the Makefile language with just file dependencies (like “a.cpp : b.h”) rather than compilation rules; thus, anything that uses make as a backend (including autotools, cmake in that mode, etc.) can just have the Makefile ‘include’ all .d files, and make will do the right thing. (Alternative backend build tools, such as ninja, have to parse the .d files themselves, typically supporting only that subset rather than reimplementing all of make!) You don’t have them for the first compile, but that’s okay: the dependencies are only used to skip recompiling files if none of their dependencies changed. This design replaced an earlier one where the user had to manually run ‘make depend’, which would pre-scan for dependencies using a separate tool, makedepend(1). First ‘gcc -M’ was added as a straight replacement of makedepend, then -MD and variants were added to write dependency files while compiling each object file rather than requiring a separate invocation (which is slower). But it sounds like modules will complicate things, since it could be mandatory to gather dependency info upfront in order to compile modules before files that depend on them...

by zach43 9y ago

mattnewport 9y ago

Build pipelines I'm familiar with typically parse the includes from a .cpp file (and potentially recursively through the included headers) and resolve the includes to actual files based on include paths specified as part of the build configuration. Sometimes this information is cached in a .dep file or by some other mechanism. This information is then used to determine what actually needs to get built by an incremental build when a header changes. The compiler is usually passed include paths to resolve includes when invoked. The build tool need to track this just to enable minimal incremental builds.

comex 9y ago

They require manual specification of include paths, but not of what .cpp files depend on what .h files. However, at least on Unix, this is not typically done by having the build tool parse C++ files. Rather, while compiling a given .cpp file, the compiler is instructed (using -MD or other variants starting with -M) to output a .d file listing all the header files it encounters as it goes, which are then treated as dependencies. The output format is a subset of the Makefile language with just file dependencies (like “a.cpp : b.h”) rather than compilation rules; thus, anything that uses make as a backend (including autotools, cmake in that mode, etc.) can just have the Makefile ‘include’ all .d files, and make will do the right thing. (Alternative backend build tools, such as ninja, have to parse the .d files themselves, typically supporting only that subset rather than reimplementing all of make!) You don’t have them for the first compile, but that’s okay: the dependencies are only used to skip recompiling files if none of their dependencies changed. This design replaced an earlier one where the user had to manually run ‘make depend’, which would pre-scan for dependencies using a separate tool, makedepend(1). First ‘gcc -M’ was added as a straight replacement of makedepend, then -MD and variants were added to write dependency files while compiling each object file rather than requiring a separate invocation (which is slower). But it sounds like modules will complicate things, since it could be mandatory to gather dependency info upfront in order to compile modules before files that depend on them...