Modules Not Laid Out Properly

[rmerriam]

My guess is that the modules are not laid out correctly. Rewriting them to test this assertion would take a lot of work. They work this way, but it isn't optimal.

Here is Snapshot.cppm.

module;

export module spectrum:Snapshot;

import peripherals;
import z80_common;

#include "spectrum/Snapshot.hpp"

#include "Snapshot.cpp"

The translation unit Snapshot.cpp should be a Module Implementation Unit, not included in the Module Interface Unit (MIU). The same is true of Spectrum.cppm and Spectrum.hpp. This pattern occurs throughout the code. I can understand why this approach was used since it is a straightforward way of converting the library to modules.

An MIU should not have any code; if it does, it should be in a private fragment. That is only valid, IMHO, for trivial code.

I cannot explain why this would cause so much relinking. Sorry I couldn't be more helpful.

[mattgodbolt]

CC @hanickadot who suggested this approach to me. I don't see the issue myself. as the .cpp file isn't even brought into the build, it's just text that's pasted into the cppm by the preprocessor, so as best I can tell it's equivalent.

[hanickadot]

I don't say I understand modules or anything. So @rmerriam is probably correct.

[mattgodbolt]

Thanks both!

I think after things settle I might do a branch that's "modules only" and do it properly there. Then I can compare

[rmerriam]

I'm less negative about this approach as I learn more. Writing the book means a steep learning curve. My target for completion is the end of May. I may get time before then to look at this since it would be a good case study in the book.

[mattgodbolt]

For what it's worth, removing the (alpha!) support for import std in CMake "fixed" one of the issues I was having (the LTO builds always rebuilding). Which makes it sound like I should report that issue to the cmake folks.

[mattgodbolt]

I'm still not sure how this ought to be done. @rmerriam did your book-writing ever come to any conclusions on this?