On 4/8/24 10:30 AM, Andrey Semashev via Boost wrote:
I find the fact that modules, including std, are not redistributable and that they must be built for every project extremely disappointing. I suspect, this will negate the potential benefit from reducing parsing when large projects like Boost are consumed as modules. Remember that we typically use only small portions of Boost, or even small portions of select Boost libraries. It doesn't make sense to have to build the whole Boost into a module only to pull a small part from it. I would much rather include the headers I want instead.
This is also relevant to the standard library. Will we have to build the ever-growing std module every time we need a smallest thing from the standard library? This sounds like a disaster to me.
One other thing that isn't clear is how modules interact with compiled libraries. I don't suppose modules will replace static/shared libraries, so I presume a module will be added on top of the library? How should it "export" the symbols that are already exported from the compiled library then?
The more I read this thread, the more it seems to me that modules are just a bad idea. We already have shared libraries which are redistributable and that's already a hassle given all the compiler switches. shared libraries have the same issue in that if one only want's to use one function, the whole library has to be shipped. The complaints regarding compile times are not even valid as far as I'm concerned. I've been on jobs where the "product" has compile times as long as 12 hours. It seems to always turn out that this is due to lazy programmers just including too much, ("convenience" headers), including the same thing over and over again (header only libraries), not understanding basic ideas like PIMPL, and not understanding the libraries they are already including, avoiding re-factoring when it's called for (they can't do it because they didn't document the libraries they included in the first place), not understanding and using explicit instantiation in the right places, etc. I don't think there is any way to fix all by just including some new already overly complex facility. Compiler vendors aren't helping either. How is it that they can't get it together and agree on a syntax for declaring visibility on library functions and types? How about some system to guarantee that compiler switches are compatible for imported code - be it in shared or unshared libraries? Then there is the committee. Stop with the doo-dads like three way if and stuff like that. Spend some more time thinking about making constexpr more automatic and still backward compatible and maybe more exportable. As for Boost, using our toolset has been a 22 year wrestling match. It looks like I need to rebuild b2 (bootstrap) when I update to the latest boost because there's some coupling somewhere. I could go on - but I'll quit while I'm ahead. Robert Ramey