On Wed, Dec 31, 2014 at 10:28 AM, Peter Dimov
Typically, when some library is installed in, say, $LIB, its headers reside in $LIB/include and its .a/.lib files in $LIB/lib. Our libraries, when built, go to $BOOST/stage/lib, which is close enough. But our header directory is just $BOOST, which doesn't seem right, as the whole of Boost is accessible through it.
It makes sense, at least to me, to have the headers in $BOOST/include/boost, instead of just $BOOST/boost.
+1
I'm not saying that we should switch right away or something like that, but am I the only one to whom such a switch (at some unspecified time in the future) seems a good idea?
Short response: I think bpm when it goes live should install the new directory structure, but we should continue for awhile to ship the monolithic .zip/etc files with the old structure. Long response: There are several different install directory structures to consider: * The directory structure developers install via git commands. Let's hope that doesn't change greatly for the foreseeable future, although it may evolve slowly. Change here is disruptive to library developers. * The directory structure installed by users via the traditional monolithic "Getting started..." zip file procedure. Because users may have a large investment in setups that assume this traditional directory structure, any change would be painful. We need to continue to ship this directory structure for long enough to give users a chance to smoothly transition to any new structure. * The directory structure installed by a Boost Package Manager, i.e. bpm. The introduction of a new modular way to install Boost is the ideal time to introduce a new install directory structure. Now. Not later. Don't release bpm for production use until we are happy with the directory structure it will install. As to exactly what the bpm install directory structure should be, I'm quite happy with the direction Peter suggested above as the starting point for discussion. --Beman