1 Jun
2014
1 Jun
'14
12:18 p.m.
Peter Dimov wrote:
John Maddock wrote:
We also need sensible policies for dealing with optional components - a good example would be libraries that provide serialization support in a separate optional header. The library as such does not require Boost.Serialization, but quite rightly the optional "bridging" support is there. I asked about this last time this topic came up, but I saw no good answer?
I'm not sure whether this is actually a significant problem in practice. An automated dependency tracker will be confused, but that would simply be a matter of marking up the bridge header as "do-not-track" in some way, wouldn't it?
I agree it probably won't be a big problem. -Julian