Yes, I personally agree. But my question actually is, there are library vendors don't buy it. For example, the libc++ developers say no explicitly.
In that case we need a proposal on how to annotate, in the code of the importable unit, that the importing unit must generate weak versions of the symbols that would otherwise be provided by the library
Trying to handle this only in the build system is a really bad idea, IMHO.
Daniel
Yes, to support "interface only" modules we need some syntax attached to the module declaration. The next question is does that mean that only the compiler generated symbols are weak? Or that even strong definitions belonging to the module are made weak?
There's also two different ways to handle this. One is that you can have multiple object files for an interface unit in a single program, but you only need one per build environment. The second is that every TU that imports (transitively) that interface unit needs to emit all used symbols into its object file. The second is terrible and brings us back to headers in terms of codegen cost. I'm not sure if CMake can do the first option though. It would be very nice to not support the second option.
- Michael Spencer