On 7/26/2017 4:22 PM, Niall Douglas via Boost wrote:
On 25/07/2017 23:16, Peter Dimov via Boost wrote:
Niall Douglas wrote:
The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.
I'm not sure if this is a question or a statement. But in either case, yes it does.
My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.
And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.
This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!
I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only. Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves. Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.
The big reason I keep advocating in favour of specific cmake targets for header-only libraries is because it solves auto-linking for all platforms without using linker magic. I think that a nice win for end users. It also could be extended easily to transparently use C++ Modules in the future, another nice win for end users.
Can you suggest where, in the case of Boost, it would be important to support dependent libraries changing their header only usability?
Niall