On 4/11/17 4:10 PM, Gavin Lambert via Boost wrote:
While I agree with this practice in general, in the specific case of Boost libraries using ../include relative paths is not a good idea, in my view.
The problem with this is the way the source is repackaged as a monolithic zip/tarball -- all of the include directories are removed and replaced with a "boost" folder that combines the include directories from all libraries.
I think it's more accurate to say that it creates a directory structure of file links which create the appearance of a monolithic boost "procuct". b2 headers is the magic command which creates this structure.
Thus an end user who only uses this zip/tarball version of Boost cannot build your tests/examples without modifying the source to use
includes instead -- so this is what you should have used to begin with.
Actually, my whole motivation was for users to be able to build the examples and run tests without having to create links to all the headers in the main boost directory. b2 headers only does this for libraries which have been "installed" into the boost. There is no tool/mechanism for doing such a think with non boost libraries. The current approach permitted a library user to build and run the examples without adding the library to the boost tree and running b2 headers and without adding an -I switch or environmental variable. But the downside is that I have these sort of funky path names for included header files. I would like one to easily be able to install/uninstall a particular library without the whole b2 headers back and forth. I would actually be happy with just adding another -I switch for each library I use directly. Its typically a small number. But that doesn't deal with the indirectly used boost libraries. After I move it to the boost subprojects, I can just follow the normal rules so in practical terms its not a huge issue for this one library. I'm really questioning the idea of depending on b2 headers and having the directory structure inside a library include the "boost" subdirectory - which has no syblings.
Having said that, as long as the library isn't actually part of the Boost distribution yet it might be more convenient to keep relative paths (since the headers don't get moved), but it's one more thing that needs to be fixed up later.
I won't save anything by fixing it sooner so I'll leave it for last as I've already a lot to do. Robert Ramey