I have a rather large codebase, that I want to start porting to C 20-modules. The layout is (roughly) like this:

SDK/System > Engine > Editor

In the order of they reference each other (editor uses engine, etc...).

My main interest would be, to first port SDK, and then Engine to modules. Editor is the least important in that regard. However, from my first attempts and research, you would have to start bottom-up, since if "SDK" is modularized, if "Editor" still uses header-includes, it wouldn't be able to use the modules.

Is this correct? If so, is there any way around it? I have seen some attempts by using #ifdefs to have both modules and header based approaches, but this would remove much of the benefit from using modules in the first place. Or do I really have to port all the consumer-code before I can start porting the shared libraries?

CodePudding user response：

A file that is not a module unit can import module units just fine. You can even #include a header which has import directives in it (not that this is a good idea). And module units can #include headers just fine, so long as you do it in the global module fragment, before the main module declaration.

What you can't do is create a module unit and expose its interface to some other file via a header that does not import that module unit. Once something is in a module, it can only be accessed via import.