4 ms·
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 m
by 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 agoI 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.