On 7/05/2019 15:57, Rene Rivera wrote:
I'm not sure those are strictly necessary, as long as the system can cope with a "partial checkout" and can ignore missing submodules.
What system are you thinking of? Does it already exist?
B2 already exists, yes.
Removing the single include directory would just break existing code and documentation, with not really any particular benefit that I can see?
How would it break existing code? And what code would it break? I ask because I know for a fact that it doesn't break existing code. As not having a single include directory works perfectly well with the modular Conan Boost packages.
As long as the <boost/> prefix is retained, then it's probably ok. I was thinking that doing something else was being proposed. Although adding >100 library paths to the include path if someone does want to (or happens to) use all of Boost doesn't particularly strike me as an improvement.
This can get a little tricky in some cases, as previously discussed. For example, if Optional depends on Serialization only if you include a specific header file (which is not included by the default
) -- is that a dependency or not? It is.
This is where circular dependencies and too-eager dependencies come from, though. If a user wants to use Optional without downloading Serialization, they would never include that header file, and thus Optional does not "really" depend on Serialization for their usage, thus it should not be downloaded. If the user wants to use both, then they're probably using Serialization elsewhere already, so they would already be downloading both, and can then use that header. So nothing actually needs to consider Serialization a dependency of Optional -- both are simply dependencies of the consuming app/library.