Subject: Re: [boost] Directory structure not quite right yet?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-06 10:37:09
Beman Dawes wrote:
> * 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.
Note that in the .tar.gz/.tar.bz2/tar.xz case we can use include/ for the
headers and put a symlink boost -> include/boost in the archive in order to
not break existing uses.
In fact, for the tar files, we can even leave the headers in libs/*/include
and ship symlinks in include/, to faithfully mirror the source tree. Which
will allow boostdep to work. :-)
We can't put a symlink in .zip or .7z though. :-(
> * 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.
The problem here is obviously that the version of Boost.Build installed by
bpm would need to support the new directory structure. When the two
structures (source tree and bpm) are the same, or supported by the same
Boost.Build, the package script can just "tar cf build.tar.lzma tools/build/
Jamroot boostcpp.jam libraries/Jamfile.v2" from the source tree, and call it
a day. But if the bpm structure requires a custom version of Boost.Build,
(a) the package script would have to do more work and (b) this custom
version of Boost.Build will need to be tested separately. In the same
structure case, the packager may (reasonably) assume that Boost.Build has
already been tested.
PS: Beman, you have an open pull request in system for meta/libraries.json.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk