On 7/8/19 7:58 AM, Richard Biener wrote:
On Mon, Jul 8, 2019 at 1:46 PM Nathan Sidwell <nat...@acm.org> wrote:One of the facilities C++ modules provides is turning header files into header units. Thus you can say: import <iostream>; (there are some constraints on being able to do that) This involves compiling the header file, similar to PCH. However, needing to provide the full path to the header file on the command line is awkward, and creates adoption friction, because it's one of the first thing someone might do. So, I've added a mechanism to search: g++ --lang c++ -std=c++17 -fmodule-header -search-system iostream I've decoupled these new options from what one does with the file (hence the -fmodule-header), or what language (hence --lang c++). Question: Are -search-system and -search-user sensible names? Should they be more clearly tied to the main file?Hmm. How would this integrate with makefiles and dependency generation? IMHO that's something to try get right first before the above.
If you have the full path, you can still use it (which is what I imagine the second iteration of a build might have). Oh, and I do have a hacked up Make that can communicate with in-flight compiles about this stuff. It's a little bitrotten right now, but demoed at the February C++ meeting. It was a PoC that build systems could cope. In that situation GCC asks using the resolved pathname of the header file. (The hacked Make is not *required* for C++ modules, it just makes things easier.)
As I said, this is addressing users' perception of ease. I've already been asked, 'I have to wrap the system headers in another header?', followed by 'why doesn't the compiler already know where iostream is?'. Also, 'why doesn't the compiler just go build it for me?'
nathan -- Nathan Sidwell
