5 ms·

> Build tools will parse source files over time and keep track of which modules are where and which translation unit needs what. Isn't this is what cmake does?

• humanrebar 9y ago
  In vanilla cmake, you declare an ordered list of include directories. But the point about "how does it work now?" is fair. I'm confused why a module search path is any worse than an include search path.
  • lultimouomo 9y ago
    This is not related to the search path, but to determining which files need to be rebuilt when a file changes. The idea is that when you change a module, you might need to recompile all the modules that include it, since its interface might have changed. What I don't get in this criticism is that you have this exact problem right now with headers, and it has been solved by the preprocessor outputting dependency information (based on #include directives) for the build system to read. Why can't the same be done with modules (of course it might not be the preprocessor that does it, but the compiler or a specific tool)?
    • humanrebar 9y ago
      I think I'm catching on. With a '#include', you give a file name. With an 'import', you give a module name, which doesn't necessarily map to a file name. So the problem could be solved by saying 'import foobar;' maps to a file (on a search path, maybe) named exactly "foobar". But then we need to work out how subdirectories and module names map to each other. How do you import "foo/bar.ixx"? "foo.bar"? "<foo/bar>"? Though all that seems technically solvable to me. Maybe there's just difficulty in designing this in the context of a committee.
  • mikepurvis 9y ago
    I think it's worse because even with a list of directories to look in, you still don't know what _file_ contains the module you're looking for. Literally, you need to open up each file in each directory of the specified search path and possibly even _run it through the preprocessor_ in order to determine if it's the module you're looking for. And assuming you don't want to do all this every time, then you need to maintain a cache somewhere, and all of this logic has to be part of the compiler rather than the build system. Anyway, Java dealt with a bunch of this by enforcing that the file naming and directory hierarchy would match the class hierarchy.
• majewsky 9y ago
  An alternative approach to parsing headers is to observe which files the compiler reads when compiling a certain source file, and recording these as dependencies of the source file. At least tup(1) can do that: http://gittup.org/tup/ http://gittup.org/tup/
• Too 9y ago
  I think cmake invokes the compiler to get header file dependencies generated as make. Such as -MM flag in gcc.
  • ndh2 9y ago
    I've never heard that before. Do you maybe have a source for that? The Visual Studio compiler is way too slow for that to work on a big code base, so I highly doubt that this is true.
    • Too 9y ago
      To clarify, cmake doesn't directly invoke the compiler. It generates a makefile that will ask gcc to generate make-dependencies when it's compiling (the first clean build doesn't need dependency info as everything is rebuilt anyway so this works). These dependencies are then included in the makefiles in subsequent runs. Cmake itself doesn't need to know about them. When using cmake to generate VS projects it probably does something equivalent, unless msbuild has dependency tracking built in out of the box, I don't know msbuild very well.
• ndh2 9y ago
  I don't think you recall correctly. CMake is not a build tool in that sense (invokes compiler/linker), it's a build generator. The build tool that actually has to track headers is whatever runs on the output of CMake.