30 May
2014
30 May
'14
12:23 p.m.
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?