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.

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 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 Mon, Sep 1, 2014 at 5:40 AM, Vladimir Prus 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 09/01/2014 04:55 PM, Rene Rivera wrote:

On Mon, Sep 1, 2014 at 5:40 AM, Vladimir Prus 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