3 ms·

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 pat

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.

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.