[build] b2 headers don't work for sublibs
Hi, I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows: libs mpl book core include boost <- here and below are core headers test index.html doc example include boost <- here and below are the rest headers meta preprocessed test .git .gitattributes README.md index.html sublibs The problem is when I run 'b2 headers' the command creates a symlink boost/mpl pointing to libs/mpl/include/boost/mpl, which leaves out all headers from libs/mpl/core/include/boost/mpl. How do I instruct Boost.Build to create links to the core headers?
AMDG On 08/30/2014 11:09 AM, Andrey Semashev wrote:
I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows:
libs mpl book core include boost <- here and below are core headers test index.html <snip>
The problem is when I run 'b2 headers' the command creates a symlink boost/mpl pointing to libs/mpl/include/boost/mpl, which leaves out all headers from libs/mpl/core/include/boost/mpl. How do I instruct Boost.Build to create links to the core headers?
Jamroot has this: local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost ] ] ; which won't find the libs/mpl/core/include subdirectory. In Christ, Steven Watanabe
On Saturday 30 August 2014 14:39:31 Steven Watanabe wrote:
AMDG
On 08/30/2014 11:09 AM, Andrey Semashev wrote:
I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows:
libs
mpl
book core
include
boost <- here and below are core headers
test index.html
<snip>
The problem is when I run 'b2 headers' the command creates a symlink boost/mpl pointing to libs/mpl/include/boost/mpl, which leaves out all headers from libs/mpl/core/include/boost/mpl. How do I instruct Boost.Build to create links to the core headers?
Jamroot has this:
local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost ] ] ;
which won't find the libs/mpl/core/include subdirectory.
Does it mean that sublibs are not supported or that this is a bug? BTW, I can see the similar approach has been taken in Boost.Chrono, and its stopwatches headers are also not linked into boost/chrono.
Andrey Semashev wrote:
On Saturday 30 August 2014 14:39:31 Steven Watanabe wrote: ...
Jamroot has this:
local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost ] ] ;
which won't find the libs/mpl/core/include subdirectory.
Does it mean that sublibs are not supported or that this is a bug?
Jamroot at the moment only supports sublibs in numeric: local numeric-headers = [ MATCH .*libs/numeric/(.*)/include/boost : [ glob libs/*/*/include/boost ] ] ; I'd call that a bug.
Le 31/08/14 01:27, Peter Dimov a écrit :
Andrey Semashev wrote:
On Saturday 30 August 2014 14:39:31 Steven Watanabe wrote: ...
Jamroot has this:
local all-headers = [ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost ] ] > ;
which won't find the libs/mpl/core/include subdirectory.
Does it mean that sublibs are not supported or that this is a bug?
Jamroot at the moment only supports sublibs in numeric:
local numeric-headers = [ MATCH .*libs/numeric/(.*)/include/boost : [ glob libs/*/*/include/boost ] ] ;
I'd call that a bug.
I added the following patch to Jamroot when I tested the stopwatch. I have not committed it as it was quite late on the release period git diff Jamroot diff --git a/Jamroot b/Jamroot index 7a7e2de..8c34b51 100644 --- a/Jamroot +++ b/Jamroot @@ -147,7 +147,7 @@ for dir in $(all-headers) } local numeric-headers = - [ MATCH .*libs/numeric/(.*)/include/boost : [ glob libs/*/*/include/boost ] ] ; + [ MATCH .*libs/numeric/(.*)/include/boost : [ glob libs/numeric/*/include/boost ] ] ; for dir in $(numeric-headers) { @@ -155,9 +155,18 @@ for dir in $(numeric-headers) explicit numeric-$(dir)-headers ; } +local chrono-headers = + [ MATCH .*libs/chrono/(.*)/include/boost : [ glob libs/chrono/*/include/boost ] ] ; + +for dir in $(chrono-headers) +{ + link-directory chrono-$(dir)-headers : libs/chrono/$(dir)/include/boost : <location>. ; + explicit chrono-$(dir)-headers ; +} + if $(all-headers) { - constant BOOST_MODULARLAYOUT : $(all-headers) $(numeric-headers) ; + constant BOOST_MODULARLAYOUT : $(all-headers) $(numeric-headers) $(chrono-headers) ; } project boost @@ -235,7 +244,7 @@ for local l in $(all-libraries) } } -alias headers : $(all-headers)-headers numeric-$(numeric-headers)-headers : : : <include>. ; +alias headers : $(all-headers)-headers numeric-$(numeric-headers)-headers chrono-$(chrono-headers)-headers : : : <include>. ; explicit headers ; # Make project ids of all libraries known. Vicente
On Sunday 31 August 2014 11:45:22 Vicente J. Botet Escriba wrote:
Le 31/08/14 01:27, Peter Dimov a écrit :
Andrey Semashev wrote:
On Saturday 30 August 2014 14:39:31 Steven Watanabe wrote: ...
Jamroot has this:
local all-headers =
[ MATCH .*libs/(.*)/include/boost : [ glob libs/*/include/boost
] ] > ;
which won't find the libs/mpl/core/include subdirectory.
Does it mean that sublibs are not supported or that this is a bug?
Jamroot at the moment only supports sublibs in numeric:
local numeric-headers =
[ MATCH .*libs/numeric/(.*)/include/boost : [ glob
libs/*/*/include/boost ] ] ;
I'd call that a bug.
I added the following patch to Jamroot when I tested the stopwatch. I have not committed it as it was quite late on the release period
I created this pull request to fix it permanently: https://github.com/boostorg/boost/pull/35
On 08/30/2014 09:09 PM, Andrey Semashev wrote:
Hi,
I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows:
libs mpl book core include boost <- here and below are core headers test index.html
Andrey, the pull request down the thread looks simple enough, and I understand you're trying to improve modularity of the code. On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before? - Volodya
On Monday 01 September 2014 08:46:53 Vladimir Prus wrote:
On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before?
I asked about MPL recently in this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/253920 There were a few more general threads about sublibs in the recent past: http://thread.gmane.org/gmane.comp.lib.boost.devel/252054 http://thread.gmane.org/gmane.comp.lib.boost.devel/236737 So the ability to create sublibs seems to be the common knowledge, and everyone decides whether to use it or not for their benefit. I'm not sure there was an official announcement from Boost.Build team or the Steering Committee though.
On 09/01/2014 11:01 AM, Andrey Semashev wrote:
On Monday 01 September 2014 08:46:53 Vladimir Prus wrote:
On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before?
I asked about MPL recently in this thread:
http://thread.gmane.org/gmane.comp.lib.boost.devel/253920
There were a few more general threads about sublibs in the recent past:
http://thread.gmane.org/gmane.comp.lib.boost.devel/252054 http://thread.gmane.org/gmane.comp.lib.boost.devel/236737
So the ability to create sublibs seems to be the common knowledge, and everyone decides whether to use it or not for their benefit. I'm not sure there was an official announcement from Boost.Build team or the Steering Committee though.
Thanks for the explanation - it appears there's enough support for this idea; I've added these links to commit message of your patch and merged to develop. - Volodya
On Mon, Sep 1, 2014 at 5:40 AM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 09/01/2014 11:01 AM, Andrey Semashev wrote:
On Monday 01 September 2014 08:46:53 Vladimir Prus wrote:
On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before?
I asked about MPL recently in this thread:
http://thread.gmane.org/gmane.comp.lib.boost.devel/253920
There were a few more general threads about sublibs in the recent past:
http://thread.gmane.org/gmane.comp.lib.boost.devel/252054 http://thread.gmane.org/gmane.comp.lib.boost.devel/236737
So the ability to create sublibs seems to be the common knowledge, and everyone decides whether to use it or not for their benefit. I'm not sure there was an official announcement from Boost.Build team or the Steering Committee though.
Thanks for the explanation - it appears there's enough support for this idea; I've added these links to commit message of your patch and merged to develop.
I, and others, have expressed dislike for that structure.. http://lists.boost.org/Archives/boost/2014/06/213998.php So it would be nice if we stopped using it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Monday 01 September 2014 07:55:45 Rene Rivera wrote:
I, and others, have expressed dislike for that structure..
http://lists.boost.org/Archives/boost/2014/06/213998.php
So it would be nice if we stopped using it.
I'm not sure I understand the problem with sublibs. Could you elaborate?
On 09/01/2014 04:55 PM, Rene Rivera wrote:
On Mon, Sep 1, 2014 at 5:40 AM, Vladimir Prus <ghost@cs.msu.su> wrote:
On 09/01/2014 11:01 AM, Andrey Semashev wrote:
On Monday 01 September 2014 08:46:53 Vladimir Prus wrote:
On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before?
I asked about MPL recently in this thread:
http://thread.gmane.org/gmane.comp.lib.boost.devel/253920
There were a few more general threads about sublibs in the recent past:
http://thread.gmane.org/gmane.comp.lib.boost.devel/252054 http://thread.gmane.org/gmane.comp.lib.boost.devel/236737
So the ability to create sublibs seems to be the common knowledge, and everyone decides whether to use it or not for their benefit. I'm not sure there was an official announcement from Boost.Build team or the Steering Committee though.
Thanks for the explanation - it appears there's enough support for this idea; I've added these links to commit message of your patch and merged to develop.
I, and others, have expressed dislike for that structure..
http://lists.boost.org/Archives/boost/2014/06/213998.php
So it would be nice if we stopped using it.
I think that decision would have to be made by SC. What apparently is happening is that everything-is-repo approach to modularization has proved rather inconvenient, and people are not thrilled about splitting libraries such as Boost.MPL into further git repositories. Arguments can be made both ways; for the time being it seems that generic code in Jamroot is better than special treatment for numeric. - Volodya
Vladimir Prus wrote:
On the other hand, was this directory structure ever explicitly discussed on this list, and agreed to? It seems to basically put two libraries inside one git repository - which is not arrangement done before?
This is the existing arrangement for libs/numeric. The header support in Jamroot was hardcoded to only look in numeric for sublibs. The testing part is more general and supports it everywhere, if a file named 'sublibs' is present (as far as I know). I don't know what the build part does.
participants (6)
-
Andrey Semashev -
Peter Dimov -
Rene Rivera -
Steven Watanabe -
Vicente J. Botet Escriba -
Vladimir Prus