Vladimir Prus wrote:
On 01/03/2015 06:29 PM, Peter Dimov wrote:
Vladimir Prus wrote:
The only important aspect though, speaking as release manager, is that if we change this now, we'll likely break a huge number of user build and automation scripts that expect current layout, lots of instructions on the web using current layout, and so forth.
Not if we symlink boost to include/boost, I think.
Fair enough, though it would seem that having $BOOST_ROOT/include/boost directory and a $BOOST_ROOT/boost symlink, along with pre-existing scripts and instructions and some "new" ones only adds to complexity/confusion, not improves anything...
The symlink will be a transitory measure, to avoid breaking existing user scripts. The official <include> location from that point on will be "$BOOST_ROOT/include".
... - unless you'll use the new layout for some completely different workflow?
The workflow I have in mind is this: -- Download bpm.zip, extract bpm.exe and bpm.conf to d:\boost-1.60.0 -- Suppose I only need Boost.System: D:\boost-1.60.0>bpm install system bpm: installing module 'system' bpm: installing module 'assert' bpm: installing module 'config' bpm: installing module 'core' bpm: installing module 'predef' bpm: installing module 'build' bpm: the following libraries need to be built: system bpm: (use ./b2 to build) bpm: recreating header links bpm: recreating index -- The "recreating header links" step puts the header links into C:\boost-1.60.0\include. D:\boost-1.60.0>b2 toolset=msvc-8.0 Building the Boost C++ Libraries. Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes Component configuration: - system : building ...found 261 targets... ...updating 18 targets... [...] ...updated 18 targets... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: D:\boost-1.60.0\include The following directory should be added to linker library paths: D:\boost-1.60.0\stage\lib -- So the user adds -I D:\boost-1.60.0\include and -L D:\boost-1.60.0\stage\lib to his project and everything is fine thereafter. I could have symlinked include/boost to boost instead, but it didn't feel right. Or, I could have symlinked boost to include/boost, without touching Jamroot, but then the headers target sees that boost is a symlink, removes it, and proceeds to make its own copies (that's part of its logic - boost is a split directory). So I patched Jamroot and boostcpp.jam instead: diff --git a/Jamroot b/Jamroot index 8885fd5..2510dc2 100644 --- a/Jamroot +++ b/Jamroot @@ -142,7 +142,7 @@ local all-headers = for dir in $(all-headers) { - link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>. ; + link-directory $(dir)-headers : libs/$(dir)/include/boost : <location>include ; explicit $(dir)-headers ; } @@ -152,7 +152,7 @@ if $(all-headers) } project boost - : requirements <include>. + : requirements <include>include # Disable auto-linking for all targets here, primarily because it caused # troubles with V2. <define>BOOST_ALL_NO_LIB=1 @@ -164,7 +164,7 @@ project boost <toolset>como-linux:<define>_GNU_SOURCE=1 # When building docs within Boost, we want the standard Boost style xsl:paramboost.defaults=Boost - : usage-requirements <include>. + : usage-requirements <include>include : build-dir bin.v2 ; @@ -226,7 +226,7 @@ for local l in $(all-libraries) } } -alias headers : $(all-headers)-headers : : : <include>. ; +alias headers : $(all-headers)-headers : : : <include>include ; explicit headers ; # Make project ids of all libraries known. diff --git a/boostcpp.jam b/boostcpp.jam index 7d7f941..230f5ad 100644 --- a/boostcpp.jam +++ b/boostcpp.jam @@ -500,7 +500,7 @@ rule post-build ( ok ? ) { if $(ok) { - local include-path = [ path.native $(BOOST_ROOT) ] ; + local include-path = [ path.native $(BOOST_ROOT)/include ] ; ECHO " The Boost C++ Libraries were successfully built! -- There do exist Jamfiles that use <include>../../.. <include>$BOOST_ROOT (those two amount to the same thing, but are repeated for some reason), but I tried a few at random and they seemed to work with the new location without any changes.