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! 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 -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/