Ruben Perez wrote:
This problem seems to make modules an all or nothing proposition. If one Boost library is a module, everything else also must be. We can't really mix and match modules and includes on a per-library basis as I envisaged. And things would be simplified considerably if we can also extend this to the standard library. It's either both import boost.* and import std, or neither.
What I've written until now assumes exactly this. It may be a lot to assume, but if you do need to mix, you can just use headers. I may be completely wrong, and mixing includes and imports will become important in the future. It felt fair to make this assumption (at least now) because the standard library seems to do it, too.
In the general case, the user will have to build all of his dependencies using a consistent setting of the "use Boost modules" macro, because otherwise a prebuilt library may well include something Boost. Which is going to be a problem if that prebuilt library is installed by a package manager, especially the system package manager. I suppose that's already a problem a theory, but modules might be more sensitive to it.