On Fri, Sep 29, 2017 at 4:25 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:

On 9/29/2017 1:02 PM, paul via Boost wrote:

...

Hi all,

So I have been working at converting more of boost tests to cmake utilizing the BCM library, here:

https://github.com/boost-cmake/boost/tree/1.64

This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake:

cd build mkdir build

Shouldn't this be:

mkdir build cd build

Yes

...

cmake .. cmake --build . --target check

This will build all the tests. You can check the tests for one target with:

cmake --build . --target check-boost_core

Which will run the tests for just `boost_core`.

This was all generated using scripts in https://github.com/pfultz2/boost-cmake

I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in.

Thanks, Paul

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 9/29/17 9:33 PM, Robert Ramey via Boost wrote:

On 9/29/17 10:02 AM, paul via Boost wrote:

...

Hi all,

So I have been working at converting more of boost tests to cmake utilizing the BCM library, here:

https://github.com/boost-cmake/boost/tree/1.64

I'm also not seeing a) how one just builds the library without running the tests? b) how one builds dynamic/shared library versions c) how one includes all that is required by an IDE. To see how this last can be done, you can look at my CMakeLists.txt in the serialization library. Robert Ramey

On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

On 9/29/17 10:02 AM, paul via Boost wrote:

...

Hi all,

So I have been working at converting more of boost tests to cmake utilizing the BCM library, here:

https://github.com/boost-cmake/boost/tree/1.64

This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake:

cd build mkdir build cmake .. cmake --build . --target check

This will build all the tests. You can check the tests for one target with:

Looking at the serialization library test because I'm familiar with it I  see things like:

serialization_archive_test(test_forward_list A)

while in the CMakeLists.txt file I see

[ test-bsl-run_files test_forward_list_ptrs : A  : :  [ requires  cxx11_hdr_forward_list ] ] # BOOST_NO_CXX11_HDR_FORWARD_LIST

In otherwords, the CMake version will run tests which cannot pass.

Currently, the feature checking from Boost.Config has not been implemented yet, although this could be fix with a simple `check_include_file`.  Of course, this is just an initial implementation of the tests in cmake. There are many areas that need updates from authors, especially since they understand the test cases better than me. So, any PRs(or feedback) are welcomed to help improve the tests.

...

cmake --build . --target check-boost_core

Which will run the tests for just `boost_core`.

This was all generated using scripts in https://github.com/pfultz2/boost-c make

Where is the document which describes how to uses these scripts?

https://github.com/pfultz2/boost-cmake

...

I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in.

I think it's a waste of time trying to apply this to all of boost until  one has demonstrated that the system actually works on test cases.  That  is what we're really going to review here is a library of CMake macros  and these need to testable/demonstrably correct independent of any  particular libraries.

Well we need to know that the cmake modules are sufficient. There are tests for BCM itself, but this says nothing about how well it will work with boost libraries.  Also, doing this in parallel can help move boost quicker to cmake.

To put it another way:

a) Develop and test the system

Thats what is being done.

If that passes and is accepted

b) Apply to all the libraries desired.

No, apply to all libraries period, as authors of upstream libraries shouldn't hold back a library from moving to cmake. .

On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:

On 10/2/17 8:27 AM, paul via Boost wrote:

...

On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

Thats what is being done.

...

If that passes and is accepted

b) Apply to all the libraries desired.

No, apply to all libraries period, as authors of upstream libraries shouldn't hold back a library from moving to cmake.

I think it would be unwise to presume that you can enforce this.

I believe that is what the SC decision was about.

Such  approaches have failed in the past. You would be better served by  focusing on creating a system whose benefits are sufficiently compelling  that the question of imposing the new system doesn't arise.  

One of the important use cases to support cmake in boost, is to move away from problematic find modules for `find_package`.  For example, you may want to support cmake in Boost.Serialization, but Boost.Iterator does not desire to update to cmake. So now you will need to create a Findboost_iterator.cmake module for Boost.Serialization. Not only that, but any downstream users of Boost.Serialization will need to a copy of the Findboost_iterator.cmake module. Now when the usage requirements for Boost.Iterator changes all these modules will be wrong. With the large number of libraries in boost, having boost half-implemented in cmake will just be a nightmare for users. They will need to figure out which libraries have cmake support and which ones need find modules. They will need to fix the modules on their own when the usage requirements for non-cmake libraries change.  Also, a lot of the libraries are very intertwined, so its not really possible to update to cmake piecewise. For example, to implement the build and tests in cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and detail, which these libraries already depended on Boost.Config as well.

To me this  is the main benefit of having such tooling ideas go through the boost  review process.

The system is already defined by cmake, adn BCM doesn't plan to change that.. The modules are just there to improve the cmake's workflow in the context of boost. .

On Mon, 2017-10-02 at 10:16 -0700, Robert Ramey via Boost wrote:

On 10/2/17 9:59 AM, paul via Boost wrote:

...

On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:

...

On 10/2/17 8:27 AM, paul via Boost wrote:

...

On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

Thats what is being done.

...

If that passes and is accepted

b) Apply to all the libraries desired.

No, apply to all libraries period, as authors of upstream libraries shouldn't hold back a library from moving to cmake.

I think it would be unwise to presume that you can enforce this.

I believe that is what the SC decision was about.

Agreed.  That's why it's flawed.

...

One of the important use cases to support cmake in boost, is to move away from problematic find modules for `find_package`.

<snip>

Interesting, I look forward to seeing this topic discussed in the review.

...

Also, a lot of the libraries are very intertwined, so its not really possible to update to cmake piecewise. For example, to implement the build and tests in cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and detail, which these libraries already depended on Boost.Config as well.

Also very interesting.  Doesn't bode well for a successful  implementation.  But we're anxious to have a look.

This email update was the start of successful implementation, so I disagree..

...

...

To me this is the main benefit of having such tooling ideas go through the boost review process.

The system is already defined by cmake, adn BCM doesn't plan to change that.. The modules are just there to improve the cmake's workflow in the context of boost.

Hmmmm - so you're saying what?  That there is nothing to be gained by  the boost type of review process?

I am not saying there shouldn't be reviewed, because we want to make sure it is sufficient for developers and users.

That it's just a question telling  developers to "turn on" CMake.  That every aspect of build/test/post  results is baked into CMake and there is no ambiguity about how to use  it in this context.  Having spent significant amount of time with CMake  myself, this would be a surprise to me.

There is a effective workflow with cmake that can help cover many different use-cases as outlined by Daniel Pfeifer's Effective CMake talk, and I don't think we should stray from that.

If you really think this, we can drop the whole idea of boost style  review and just stay with the current situation.  This is that Boost  Steering committee makes a pronouncement, and developers ignore it.

I dont think this. .

On Mon, 2017-10-02 at 10:33 -0700, Rene Rivera wrote:

...

On Mon, 2017-10-02 at 08:33 -0700, Robert Ramey via Boost wrote:

...

On 10/2/17 8:27 AM, paul via Boost wrote:

...

On Fri, 2017-09-29 at 21:33 -0700, Robert Ramey via Boost wrote:

Thats what is being done.

...

If that passes and is accepted

b) Apply to all the libraries desired.

No, apply to all libraries period, as authors of upstream libraries shouldn't hold back a library from moving to cmake.

I think it would be unwise to presume that you can enforce this.

I believe that is what the SC decision was about. What I believe Robert's, and others, point on this is that the SC can make

On Mon, Oct 2, 2017 at 9:59 AM, paul via Boost <boost@lists.boost.org> wrote: pronouncements as to how things have to be. But library authors are free to ignore such pronouncements. As it's *their* libraries. Hence unless you convince them of concrete benefits over what they have now you aren't going to make a lot of forward progress. Just remember that programmers tend to be inherently lazy (except for Vinnie).

Yes, which is why I am generating an initial implementation of cmake, instead of relying on each individual author.

...

...

Such  approaches have failed in the past. You would be better served by  focusing on creating a system whose benefits are sufficiently compelling  that the question of imposing the new system doesn't arise.  

One of the important use cases to support cmake in boost, is to move away from problematic find modules for `find_package`. 

For example, you may want to support cmake in Boost.Serialization, but Boost.Iterator does not desire to update to cmake. So now you will need to create a Findboost_iterator.cmake module for Boost.Serialization. Not only that, but any downstream users of Boost.Serialization will need to a copy of the Findboost_iterator.cmake module. Now when the usage requirements for Boost.Iterator changes all these modules will be wrong. Or you could just use conan, and not force any particular build system on anyone.

Or rather you are replacing a build system with another. Or in the case of cmake, replacing a a meta-build system with a meta-meta build system(that also happens to be a package manager).  It doesn't integrate well with cmake. You can't do `add_subdirectory` with packages that conan provides.  Also, if you are in the 'install' camp, conan doesn't properly tell cmake where the dependencies are. This is why you have to add special conan cmake functions to your cmake like `conan_basic_setup`, which still has problems. If you use any of cmake's find_* command, it will no longer work because even with `conan_basic_setup`, cmake still doesn't know where your dependencies are. Furthermore, adding `conan_basic_setup` to your cmake, you are no longer supporting cmake users. You could add an additional `if` or put the conan logic in a python file to support cmake users and conan, but now you are supporting two build systems.

...

With the large number of libraries in boost, having boost half-implemented in cmake will just be a nightmare for users. They will need to figure out which libraries have cmake support and which ones need find modules. They will need to fix the modules on their own when the usage requirements for non-cmake libraries change.  Or you could tell users that conan is the public interface to Boost and not force a particular build system on anyone. 

...

Also, a lot of the libraries are very intertwined, so its not really possible to update to cmake piecewise. For example, to implement the build and tests in cmake for Boost.Config, we need cmake support for tr1, core, type_traits, and detail, which these libraries already depended on Boost.Config as well. The suggestion has been made before that it's perfectly possible to provide a build system agnostic interface to testing and other aspects of building libraries. 

It is, but the closest implementation I have seen of this is cmake. .

On Tue, 2017-10-03 at 19:58 +0300, Peter Dimov via Boost wrote:

paul wrote:

...

Hi all,

So I have been working at converting more of boost tests to cmake  utilizing the BCM library, here:

https://github.com/boost-cmake/boost/tree/1.64

This looks pretty good.

Thanks.

A few comments:

    include(bcm/share/bcm/cmake/BCMConfig.cmake)

bcm/share/bcm doesn't seem the right place. tools/bcm, more likely.

Yea, I will look into moving that.

Looking at  https://github.com/boost-cmake/boost/blob/1.64/libs/core/CMakeLists.txt as  an example, clean and tidy; but I'd like to know what is the suggested way  of keeping this file up to date. At minimum, this line:

    bcm_setup_version(VERSION 1.64.0)

needs to be updated per each release; how is this to be done?

I had the version in a separate version.cmake file for this reason; so that  version.cmake could be mass-updated by a script after each release, without  having to either regenerate all CMakeLists files - implying that all local  changes would be lost - or requiring maintainers to keep the version up to  date - which they will not.

Yea I can set it up to read the version from a file.

A similar question arises with the sources and the dependencies, although  those do not change as often or on such a fixed schedule. (I had those in  separate files as well, for similar reasons, although one could go either  way here.)

    find_package(boost_assert)

As I already mentioned a number of times, this in my opinion must be

    find_package(boost_assert VERSION 1.64.0 EXACT)

because there is never, ever, a scenario in which I want boost_core 1.64.0  to link to boost_assert 1.58.0.

The user may want to use boost_core 1.64.0 with boost_assert 1.64.1 or 1.65 because perhaps the newer version is from develop that fixes a problem they are having.

(Also, REQUIRED, as otherwise errors are not  as informative.)

True, although some dependencies are optional, which I dont really account for yet.

    target_link_libraries(boost_core INTERFACE boost::assert)

This manual specification of dependencies duplicates the find_package. These  two could potentially be folded into something like

    bcm_dependency(assert INTERFACE)

So this would be something like: function(bcm_dependency name type)     find_package(boost_${name})     target_link_libraries(${PROJECT_NAME} ${type} ${name}) endfunction() I am not sure how well that works if the user wants to make the dependency optional or required, but I think it could be made to work. I have considered adding a function like: bcm_boost_depends(boost_core assert config) In general, I was trying to avoid abstracting out too much cmake, as it makes it unfamiliar to cmake users. Plus, I would like utilities that can be eventually merged to cmake upstream. However, if there are a lot of developers who would really like to write as a above, I could definitely add it.

Moving on to  https://github.com/boost-cmake/boost/blob/1.64/libs/core/test/CMakeLists.txt ,

    bcm_test(NAME core_addressof_test SOURCES addressof_test.cpp)

In the Jamfile, this is

    run addressof_test.cpp ;

which automatically generates a name for the test. It would probably be more  convenient if bcm_test could do that itself as well, including adding a  prefix, so that

    bcm_test(SOURCES addressof_test.cpp)

declared core_addressof_test, and

    bcm_test(SOURCES addressof_test.cpp NAME addressof_test_name)

declared core_addressof_test_name so that one did not have to remember to  prefix everything with core_.

That is something I am seriously considering. Although, if you want to change the properties, a name would be needed, so for something like: bcm_test(NAME core_typeinfo_test_no_rtti SOURCES typeinfo_test.cpp) set_target_properties(core_typeinfo_test_no_rtti PROPERTIES CXX_RTTI Off) The name would probably need to stay. I am also considering having `bcm_test` enforce that names start with the project name, so it better avoids name conflicts.

Apart from that, nice work, CMake fans ought to be happy. Needs to be  brought up to date with master though. :-)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo st

.

On Wed, 2017-10-04 at 03:09 +0300, Peter Dimov via Boost wrote:

paul wrote:

...

...

As I already mentioned a number of times, this in my opinion must be

    find_package(boost_assert VERSION 1.64.0 EXACT)

because there is never, ever, a scenario in which I want boost_core  1.64.0 to link to boost_assert 1.58.0.

The user may want to use boost_core 1.64.0 with boost_assert 1.64.1 or  1.65 because perhaps the newer version is from develop that fixes a  problem they are having.

Yeah. How would this scenario come into being though? Suppose you have  1.64.0 already installed; you replace boost_assert from develop and now, as  also mentioned a number of times, you have all manners of ODR violations  because your libraries are built against boost_assert 1.64.0 and you're  including the develop one. 

If you change your dependencies, you would most likely change the library that depend on those as well.  Even if they didn't rebuild, it doesn't always mean it would lead to an ODR violation, as the change could only affect some assert macros that are not used in the definition. Of course, adding the version doesn't prevent the scenario you mention. They could just reinstall a whole new version of boost 1.65 and the libraries that were built against boost 1.64 would be broken. Or they could create a superproject of the different boost modules, with using 1.64 for everything except boost_assert. This still would affect downstream libraries that were built against an older version of boost. Paul .

On 04.10.2017 12:01, Peter Dimov via Boost wrote:

paul wrote:

...

Of course, adding the version doesn't prevent the scenario you mention. They could just reinstall a whole new version of boost 1.65 and the libraries that were built against boost 1.64 would be broken.

I'm talking about Boost libraries here, not theirs. Boost library X 1.64.0 is built against Boost library Y 1.64.0. You update Y to 1.65.0, X is now broken.

While this may be true for some (or even many) "core" Boost libraries, I believe there are enough peripheral libraries that could safely be built against multiple Boost "core" versions. And while you may not yet want to consider separating the release cycles of individual Boost libraries, I think it's a big error to design such a restriction right into the infrastructure. Not being able to build Boost libraries stand-alone (i.e., against a preinstalled set of prerequisite Boost libraries) is one of my biggest complaints against the existing Boost.Build logic. (For example, I test and run development versions of Boost.Python against various older Boost releases fairly regularly, but to be able to do that I need to use my own build system, unfortunately.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 10/4/2017 12:14 PM, Stefan Seefeld via Boost wrote:

On 04.10.2017 12:01, Peter Dimov via Boost wrote:

...

paul wrote:

...

Of course, adding the version doesn't prevent the scenario you mention. They could just reinstall a whole new version of boost 1.65 and the libraries that were built against boost 1.64 would be broken.

I'm talking about Boost libraries here, not theirs. Boost library X 1.64.0 is built against Boost library Y 1.64.0. You update Y to 1.65.0, X is now broken.

While this may be true for some (or even many) "core" Boost libraries, I believe there are enough peripheral libraries that could safely be built against multiple Boost "core" versions. And while you may not yet want to consider separating the release cycles of individual Boost libraries, I think it's a big error to design such a restriction right into the infrastructure. Not being able to build Boost libraries stand-alone (i.e., against a preinstalled set of prerequisite Boost libraries) is one of my biggest complaints against the existing Boost.Build logic.

You seem to think that without any sort of individual library versioning system whatsoever, and therefore no guarantee that a particular version of a Boost library will work with some other version of another Boost library, that distributing separate individual Boost libraries to end-users will be just fine and ducky. I don't. Nor do I think placing the burden on end-user to figure out why this will not work, when it does not, is any answer. I am not against a system where Boost may be able to distribute individual Boost libraries rather than distribute each version as a monolithic whole as it does now. But if Boost library X depends on Boost library Y, there has to be some system whereby both library X and library Y have individual versioning information and there has to be some system whereby library X version nn has to know whether or not it will work with library Y version nn, or disaster will ensue. And just saying that library X should probably work with library Y, even though both are part of different Boost releases, is not a solution for end-users IMO.

(For example, I test and run development versions of Boost.Python against various older Boost releases fairly regularly, but to be able to do that I need to use my own build system, unfortunately.)

Stefan

On Wed, Oct 4, 2017 at 9:58 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

On 04.10.2017 12:44, Edward Diener via Boost wrote:

...

On 10/4/2017 12:14 PM, Stefan Seefeld via Boost wrote:

...

On 04.10.2017 12:01, Peter Dimov via Boost wrote:

...

paul wrote:

...

Of course, adding the version doesn't prevent the scenario you mention. They could just reinstall a whole new version of boost 1.65 and the libraries that were built against boost 1.64 would be broken.

I'm talking about Boost libraries here, not theirs. Boost library X 1.64.0 is built against Boost library Y 1.64.0. You update Y to 1.65.0, X is now broken.

While this may be true for some (or even many) "core" Boost libraries, I believe there are enough peripheral libraries that could safely be built against multiple Boost "core" versions. And while you may not yet want to consider separating the release cycles of individual Boost libraries, I think it's a big error to design such a restriction right into the infrastructure. Not being able to build Boost libraries stand-alone (i.e., against a preinstalled set of prerequisite Boost libraries) is one of my biggest complaints against the existing Boost.Build logic.

You seem to think that without any sort of individual library versioning system whatsoever, and therefore no guarantee that a particular version of a Boost library will work with some other version of another Boost library, that distributing separate individual Boost libraries to end-users will be just fine and ducky. I don't. Nor do I think placing the burden on end-user to figure out why this will not work, when it does not, is any answer.

I'm not sure we actually disagree. For one, I didn't mean to re-open a discussion about separating release cycles. I merely wanted to point out a limitation in the existing Boost.Build logic, and how I hope that any future build system will support stand-alone builds, so further modularization can at least be considered and experimented with.

Not entirely sure what you are referring to... But B2 doesn't have such a limitation. So perhaps I missed something something. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Wed, Oct 4, 2017 at 10:36 AM, Stefan Seefeld via Boost < boost@lists.boost.org> wrote:

On 04.10.2017 13:22, Rene Rivera via Boost wrote:

...

...

For one, I didn't mean to re-open a discussion about separating release cycles. I merely wanted to point out a limitation in the existing Boost.Build logic, and how I hope that any future build system will support stand-alone builds, so further modularization can at least be considered and experimented with.

Not entirely sure what you are referring to... But B2 doesn't have such a limitation. So perhaps I missed something something.

Perhaps b2 the tool doesn't have such a limitation, but b2 the boost build infrastructure does, given that it's impossible to build library Boost.X stand-alone, i.e. without starting from the superproject repo. I'm pretty sure that could be fixed quickly for someone with the required knowledge, but right now that's not a supported workflow.

True. Although the existing infrastructure can be made to be modular non-intrusively. As I did for the conan modular packaging.

Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.

Couldn't agree more :-) And if that is a key requirement for the next build system it should be explicitly considered as such in future deliberations. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 04.10.2017 13:58, Vinnie Falco via Boost wrote:

...

...

Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.

Couldn't agree more :-) And if that is a key requirement for the next build system it should be explicitly considered as such in future deliberations. I disagree. I rather like the current system where there is the one monolithic distribution, and you have confidence thanks to the testing

On Wed, Oct 4, 2017 at 10:45 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote: that all of those libraries from the same Boost version are going to work together. Its an easier guarantee to uphold for the library author and it is easier to understand for the user.

That should be the choice of the library's maintainer. (I understand your concerns. However, the tradeoff varies depending on the amount of dependency between the given library and the rest of Boost, so I don't think there is a single optimal answer for all Boost libraries.)

To break this contract and now say that X needs version so and so of Y, and another version of Z, is I think to introduce needless complexity. I'm not opposed to the idea of modular builds (i.e. get just Boost.HTTPKit and Boost.Buffers without also acquiring Boost.Asio) but I prefer the simplicity of keeping them all at the same version. Update one, update all.

Again, let's not get carried away with how we should release Boost (which is a very different topic). In any case, this should be a conscious choice, not a technical limitation. If we don't even have the means to build libraries separately, we'll never even be able to find out whether different versions would be compatible and thus safe to use by end-users. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Wed, 2017-10-04 at 10:58 -0700, Vinnie Falco via Boost wrote:

On Wed, Oct 4, 2017 at 10:45 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:

...

...

Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.

Couldn't agree more :-) And if that is a key requirement for the next build system it should be explicitly considered as such in future deliberations.

I disagree. I rather like the current system where there is the one monolithic distribution, and you have confidence thanks to the testing that all of those libraries from the same Boost version are going to work together. Its an easier guarantee to uphold for the library author and it is easier to understand for the user.

I dont think being able to build against different version means that we won't test and release a set versions that work together. Thats the way any distro works. The distro tests and makes sure all the version works together, and provides the user with the set of versions that do work, but I can still manually install newer versions. Some authors may work hard so their library is compatible across several boost releases, but its not necessary for an author.  The most likely use case a user will mix and match version is to update a version to fix some bug or to get a new feature. None of this will be something boost itself will test, but a user or author may be able to make it work on their own.

To break this contract and now say that X needs version so and so of Y, and another version of Z, is I think to introduce needless complexity. I'm not opposed to the idea of modular builds (i.e. get just Boost.HTTPKit and Boost.Buffers without also acquiring Boost.Asio) but I prefer the simplicity of keeping them all at the same version. Update one, update all.

Yes, an if boost is released as a some kind of distro, its just a matter of updating your boost distro to get new versions of everything together. And of course, a modular distro release also doesn't mean we no longer support a monolithic release of boost, either.

On Wed, 2017-10-04 at 22:20 +0300, Peter Dimov via Boost wrote:

Stefan Seefeld wrote:

...

Anyhow, I'm sorry this went off a tangent. My original point was to  suggest that CMake (or any other future Boost build system) should support  modular builds, rather than expect Boost.X and Boost.Y always have the  same version, or be part of the same source tree.

I'm not sure that what I wanted to say got through, so I'll restate.

The problem is not that X and Y have to have the same version. They don't..  The problem is that Y has to have the same version.

Suppose you install Boost 1.64. You get the headers of the header-only  library Y 1.64, the headers of the non-header-only library X 1.64 (that  include the headers of Y), and the built library X 1.64 that incorporates in  itself the headers of Y 1.64.

You then upgrade Y to 1.65. Now you have the headers of Y 1.65.

Your project uses X. It includes a X header. It includes a Y header (1.65).  So your program contains Y 1.65.

Your project links to X. X has been built against Y 1.64. So your program  contains Y 1.64.

This is what we (or rather, I) want to prevent with the version check. It's  not that X 1.64 absolutely has to require Y 1.64. It could - in principle -  require something else. But once built, it has to keep requiring the version  of Y it has been built with. 

But you are requiring that X 1.64 only to use Y 1.64. If we want it that once its built, it keeps using the same version, we can have `bcm_auto_export` to always generate the `find_dependency` with an `EXACT` argument using the version Y it is built with.

On 10/4/17 10:36 AM, Stefan Seefeld via Boost wrote:

On 04.10.2017 13:22, Rene Rivera via Boost wrote:

...

...

For one, I didn't mean to re-open a discussion about separating release cycles. I merely wanted to point out a limitation in the existing Boost.Build logic, and how I hope that any future build system will support stand-alone builds, so further modularization can at least be considered and experimented with.

Not entirely sure what you are referring to... But B2 doesn't have such a limitation. So perhaps I missed something something.

Perhaps b2 the tool doesn't have such a limitation, but b2 the boost build infrastructure does, given that it's impossible to build library Boost.X stand-alone, i.e. without starting from the superproject repo.

Hmmm - I'm not seeing this. I always build all my tests from the serialization/test directory. This also automagically builds all the precursor libraries like boost/system etc. So the current setup gives me what I expect and desire in this regard.

I'm pretty sure that could be fixed quickly for someone with the required knowledge, but right now that's not a supported workflow. Anyhow, I'm sorry this went off a tangent. My original point was to suggest that CMake (or any other future Boost build system) should support modular builds, rather than expect Boost.X and Boost.Y always have the same version, or be part of the same source tree.

Correct. We have several intertwined issues: a) Build/test of boost libaries b) Posting of test results c) Dependencies d) Deployment e) import of boost libraries (modules) by users Which bring up other issues such as per library versioning, b2 headers and the like. It's going to be pretty tough to keep this discussion from getting too confusing. Robert Ramey

Stefan