On 6/16/17 4:48 PM, Vinnie Falco via Boost wrote:

On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost <boost@lists.boost.org> wrote:

...

This is a request for comments on a possible path for migrating Boost's build system to CMake.

It seems there are two concerns here:

1. Providing an up-to-date "FindBoost" module with each Boost release so that *users* who build their projects with CMake can easily find the Boost dependencies, and

a) I use XCode IDE for development of my Boost projects. So I'm familiar with it. b) CMake FindBoost doesn't work as far as I'm concerned. This means that after creating an IDE project, I have to tweak it to make it work. I looked into the FindBoost code and, as it must, it tries to automagically figure out where the libraries are, which versions, share vs linked etc.etc. It's fairly complex and would require a lot of work to work on a more or less reliable bases. In short, my view is that CMake doesn't really work - it's more that it can be made to work.

2. Allowing Boost itself to be built using CMake as an alternative to bjam

Do we need both, or is it possible to satisfy the majority of user wants by implementing only number 1 above?

We don't even have to address that question since of necessity, there would have to be a transition whereby both are supported. Eventually this would sort itself out.

Thanks

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

On Fri, Jun 16, 2017 at 7:48 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:

On Fri, Jun 16, 2017 at 4:44 PM, David Sankel via Boost <boost@lists.boost.org> wrote:

...

This is a request for comments on a possible path for migrating Boost's build system to CMake.

It seems there are two concerns here:

1. Providing an up-to-date "FindBoost" module with each Boost release so that *users* who build their projects with CMake can easily find the Boost dependencies, and

There are a significant number of users who do not use the binary distribution model for their codebases. Instead, they have the source code for all their projects (including third-party dependencies like Boost) in one repository and build everything all at once. These users cannot use CMake's FindBoost module since it doesn't have the capability to add the boost source code to the build. They currently have the choice to write and maintain their own CMake files to build boost, wrap the bjam build with CMake code, or just don't bother using Boost since it is too big a hassle. I've seen all three of these.

On Fri, Jun 16, 2017 at 8:27 PM, Edward Diener via Boost < boost@lists.boost.org> wrote:

As has been pointed out by many people Boost Build does a number of things for building, testing, and creating documentation for a library which CMake does not do, whereas I have never seen any evidence of a single thing which CMake does which Boost Build cannot do. So in effect you are asking developers to give up a superior build product for one that is vastly more popular.

That is a correct assessment.

I have even asked about a CMake deficiency on the CMake mailing list, only to receive no answer at all. That is why I have the impression that CMake deficiencies are just ignored.

Uhm, this happens with any Open Source project with a big enough user base. Can you link to your post? I do not want to debate. I am still waiting for anyone to show me CMake

building all Boost libraries, including builds, tests, and documentation, with the same results that Boost Build currently does. Anyone ? Otherwise this endless suggestion of moving to CMake, because it is so popular with the general programming world, seems an absolute dead end to me.

BTW I am no great lover of bjam syntax or the undocumented internal complexities of the Boost Build system. But unless I can be shown a CMake system that can practically do what Boost Build does for maintaining libraries I believe your suggestion is a non-starter.

This sounds a lot like "do the work first and then I'll tell you whether or not your time was wasted". This is a significant time and probably monetary investment, something worthy of discussion *before* the work is done.

On 6/16/2017 8:30 PM, Niall Douglas via Boost wrote:

...

* Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build.

Instead of nasty cmake 2 era FindBoost(), why can't end users use the modern cmake 3 pattern:

``` find_package(boost COMPONENTS asio REQUIRED) target_link_libraries(myprogram PRIVATE boost::asio) ```

No cmake innovation needed to do this. This is 100% vanilla cmake 3.

BTW David if you do decide to go down this route, you and the Steering Committee should seriously consider contracting Stephen Kelly to advise on doing this properly. He's the primary architect of cmake 3's improvements. He knows more about how to do this right than *anybody* on this list.

It would also make good on the way he was chased away from here for the sin of changing other people's code without their permission despite that Dave had asked him to and given him the svn commit privs to do so. It would be the least the Steering Committee could do to put that wrong right and officially say sorry.

He was not "chased away" and the rest of your interpretation of what happened is completely wrong.

Niall

On 16.06.2017 21:26, Robert Ramey via Boost wrote:

On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:

[...]

...

At least that's one dream I keep having...

This is the vision that I had when I made my proposal at C++Now titled Boost 2.0.

It's also the vision that I had/have in mind when I create the Boost Library Incubator.

I believe the two lines about fleshout the vision you've articulated so you've got two votes - (not that it's up for a vote).

That's good to hear (even though it's not up for a vote :-) ).

My presentation boost 2.0 was probably my least successful ever. I lost control of it as it veered into and argument about automatically generating dependencies. I was sott of struck by lightning. But still it articulated some ideas which have come to fruition such as the Boost Library Official Maintainer program and Boost Library Incubator.

It's funny how most discussions here end up as tool discussions. ("When the only tool you have is a hammer, every problem looks like a nail.")

They haven't been the total success I would have hoped, but it does seem that we have less complaints about lack of library maintenance and we are reviewing more libraries which seem better prepared for review. Of course maybe it's confirmation bias.

The last time this was discussed on the list, things circled down the drain of automatic dependencies.

Ditto.

Let's not do this again. Let's just accept that somehow dependencies will be figured out, even if it has to be done by hand.

Let's be very conscious about the fact that the problem to solve is not the technical one (which is the easy part !), but the underlying systemic (social) one. And until that is being addressed, no tool will help us.

The more interesting thing is the decoupling. Let each library decide which build, test, documentation, deployment, bug tracking system to use. The Boost Politburo would set requirements rather than design a specific system.

Right. And even those requirements would have to be carefully to be minimally intrusive...

Examples would be:

a) every libary has to have documentation. Documentation has to be standards conforming. That is it would have to describe libraries in terms of valid expressions rather than implementation

Yes ! (And for avoidance of doubt: "standards conforming" should exclusively be concerned about the outcome, not the way it is produced (which is an "implementation").

b) every library has to have a test suite

c) every library has to have a single button download, build and test functionality.

d) every library has to use a public version control system for it's source code

e) every library has to use the Boost License

f) every library has to fulfill a minimum set of directory structure requirements.

f) Review managers cannot accept library into boost if it fails any of the above.

Agreed to all of the above.

Of course the Boost web page would have a portion which looks like the Boost library Incubator. So be it. Actually I've even considered just adding a page for each current boost library. The library dropdown would then specify accepted boost libraries, proposed boost libraries, etc.

Building of all of boost would of just the sequence of "one button" download build and test for each library.

I was going to put this in a separate post by you started down this path.

Thanks for following up. Yes, I think these are good goals. Is there no way we can build up momentum around these ideas to be able to move into that direction ? (And again, please let's not focus on any technical details how we achieve the above, but first and foremost agree where we want to go.) I'd be more than willing to help in any way I can. As Boost.Python maintainer I'm trying to go down that route anyhow. But I would appreciate company ! ;-)

Robert Ramey Stefan

-- ...ich hab' noch einen Koffer in Berlin...

On 6/16/17 7:25 PM, Vinnie Falco via Boost wrote:

On Fri, Jun 16, 2017 at 6:26 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:

...

Documentation has to be standards conforming. That is it would have to describe libraries in terms of valid expressions rather than implementation

Are you saying that a description of valid expressions is the only good way to document a library?

I am.

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

On 17.06.2017 00:11, David Sankel wrote:

On Fri, Jun 16, 2017 at 8:33 PM, Stefan Seefeld via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

On 16.06.2017 19:44, David Sankel via Boost wrote: > Howdy all, > > This is a request for comments on a possible path for migrating Boost's > build > system to CMake. I am not speaking for the Boost Program Committee here, > but I > plan on bringing this up with them after getting feedback.

So instead of substituting a tool, I would like to invite you to consider a few organizational changes. Notably, I would like to see the long-stalled modularization process to be picked up again and be continued (and completed ?).

The original modularization effort called for switching to CMake, but it was decided that switching to git would be a good first step. I do think that my proposal is in support of that effort. I'd comment more on your proposal for something else, but that seems out of scope for this thread.

Can you explain how the two are related ? I understand that the current Boost.Build logic is deficient in its support for modular builds (i.e., the ability for individual projects to be built stand-alone). Making this use-case a top priority (without imposing anything in terms of how it is implemented) would be useful. But telling everybody what to do wouldn't. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <boost@lists.boost.org> wrote:

On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

...

* Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each particular library? Who would re-write and maintain this FindBoost as the current one is not up the task. Getting this right - or even better is not a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is relatively straightforward. The implementation for the Boost-source version of this library would look at the COMPONENTS argument and, based on that, add_subdirectory the source for the particularly requested library. The CMakeLists.txt file would be author maintained and provide its corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is used to find packages installed, it should never go out and build libraries. If the user wants to add boost to their build(or set of libraries), you would use `add_subdirectory` directly and then override `find_package` to ignore boost packages, and then use the `boost::` alias targets provided.

On Jun 16, 2017, at 11:54 PM, David Sankel <camior@gmail.com> wrote:

On Sat, Jun 17, 2017 at 12:34 AM, P F <pfultz2@yahoo.com <mailto:pfultz2@yahoo.com>> wrote:

...

On Jun 16, 2017, at 11:24 PM, David Sankel via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

On Fri, Jun 16, 2017 at 9:01 PM, Robert Ramey via Boost < boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

...

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

...

* Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build.

Hmmm would this be a FindBoost for the whole of Boost or for each particular library? Who would re-write and maintain this FindBoost as the current one is not up the task. Getting this right - or even better is not a trivial task.

I agree that this is a non-trivial task. The contract for FindBoost is relatively straightforward. The implementation for the Boost-source version of this library would look at the COMPONENTS argument and, based on that, add_subdirectory the source for the particularly requested library. The CMakeLists.txt file would be author maintained and provide its corresponding target (e.g. boost::thread).

Thats not the the way `find_package` works at all. The `find_package` is used to find packages installed, it should never go out and build libraries.

I don't know where you get that impression (again, see the video I linked to earlier).

None of the find modules do this, nor do libraries that provide config cmake. In fact, the video shows a lot of non-standard ways of using cmake, which is what you are proposing we avoid, and I agree with.

This is, indeed, the only way to write packages that can be built with already-installed binaries or together with the source code of their dependencies.

But you never write packages, rather you ignore the packages, like this: set(as_subproject Foo) macro(find_package) if(NOT "${ARG0}" IN_LIST as_subproject) _find_package(${ARGV}) endif() endmacro() add_subdirectory(Foo) add_subdirectory(App) This makes `find_package(Foo)` do nothing as `Foo::Foo` is part of the project. This way projects can be written to support both modular and superproject build without changing the build scripts, and without needing to use `if(NOT TARGET)` hacks.

It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).

On Jun 17, 2017, at 5:23 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

...

It is a very important property to have in a build system for large-scale development.

It is very important for boost to be able to support `add_subdirectory` builds. However, hijacking `find_package` to call `add_subdirectory` is the wrong approach and goes against cmake’s workflow. The approach I outlined is what is presented in Daniel Pfeifer’s Effective Cmake talk(although I was aware of this before Daniel’s talk).

I'm mostly in agreement with Paul here.

You may however also be in agreement too David. Here are some cmake use cases:

1. I want a library from a Boost release, so find_package(boost 1.60 MODULE COMPONENTS asio REQUIRED), link to boost::asio

We will need to update cmake so that it finds boost config packages. Or the user can say `find_package(boost_asio)`.

2. I am making a new Boost library or I am using Boost trunk source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to boost::asio

No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.

3. There is a third use case pre-C++11 Boost libraries can't do which is to mix some release Boost libraries from find_package with some brought in by add_subdirectory() from a source tree. You may wish to rule out supporting that, but equally, a correct cmake implementation should implement that just fine.

There is no reason why that can’t be supported. You only setup `find_package` to ignore the packages that are part of the build and then call `find_package` as you normally would for libraries that aren’t being built.

I do agree David that cmake innovation is to be avoided right now. I have a superb cmake innovation at the library formerly known as boost-lite and now called quickcpplib because it lets you write state of the art C++ libraries super-quick by eliminating needing to think about build or test or tooling or documentation or CI scripting, just supply the config file and go, the cmake inspects its environment and automates everything thereafter. It's really amazing. But it also is very experimental, and insufficiently tested. And it has several serious bugs I haven't got to fixing yet.

So don't innovate cmake. Just use 100% standard cmake 3.5, and make sure it is a *good neighbour* to other cmake and is not *anti-social* like most cmake currently written today. Design the cmake to be usable as build and discovery drivers by other cmake. This is the key improvement in cmake 3 - being nice to **any** other cmake.

I'd recommend a minimum of cmake 3.5.

I agree we should use cmake 3.5 as a baseline, as that is what comes with ubuntu 16.04.

You can create header only library targets and >= 3.5 those work right without bugs. You can create static and dynamic library targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the dependencies. Libraries like Hana can “cheat” and export the targets directly to the cmake config package because it has no dependencies. However, for a library like Boost.Fusion the dependencies will need to be listed a third time in the cmake config.

I would personally suggest a Python script which parses Jamfile.v2 and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough using just this.

We can generate the code with python, which will help with libraries that have lots of dependencies. Although some libraries like Boost.Config is not so simple.

You just then need to feed everything to the cmake package tooling, again all 100% cmake 3. And you should be done, no cmake innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow, rather it is tool to help reduce the boilerplate needed to provide cmake support in libraries like boost. Otherwise we will have authors create their own set of functions to make the build scripts more maintainable, and then we will lose consistency among boost libraries.

As Edward pointed out, not everything Boost.Build can do will work in cmake without cmake innovation. But worry about that after, for end users of Boost they almost certainly have no need nor want for any of the stuff beyond already described. Indeed one argument could be "don't move Boost to cmake, *package* Boost releases with auto-generated cmake build support". That would make for happy end users.

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having pkgconfig would be helpful as well.

Niall Douglas wrote:

So tl;dr; I strongly recommend placing all cmake complexity into runnable scripts which generate .cmake files to be include()d to avoid boilerplate, and keep the CMakeLists.txt etc completely free of any custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file should, in your opinion, look like, for a run-of-the-mill Boost library? Pick some existing library to illustrate the point, such as for example System, or SmartPtr, or even the simplest one, Assert. Or any other, if you prefer.

...

So tl;dr; I strongly recommend placing all cmake complexity into runnable scripts which generate .cmake files to be include()d to avoid boilerplate, and keep the CMakeLists.txt etc completely free of any custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file should, in your opinion, look like, for a run-of-the-mill Boost library? Pick some existing library to illustrate the point, such as for example System, or SmartPtr, or even the simplest one, Assert. Or any other, if you prefer.

Sure, though I'm talking really vanilla cmake here. But I guess it will narrow the discussion by demonstrating idiomatic cmake 3. Too much cmake 2 still kicks around. I really wish cmake would kill off cmake2-isms, as in, refuse to use them. According to Jens' https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System looks the most tractable. I'll see if I can find some hours to do it up, I can guarantee it won't be today nor tomorrow. Maybe tomorrow night after the kids are asleep. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 6/17/17 10:30 AM, Niall Douglas via Boost wrote:

...

...

So tl;dr; I strongly recommend placing all cmake complexity into runnable scripts which generate .cmake files to be include()d to avoid boilerplate, and keep the CMakeLists.txt etc completely free of any custom macros or functions.

Niall, could you please show how an idiomatic CMakeLists.txt file should, in your opinion, look like, for a run-of-the-mill Boost library? Pick some existing library to illustrate the point, such as for example System, or SmartPtr, or even the simplest one, Assert. Or any other, if you prefer.

Sure, though I'm talking really vanilla cmake here. But I guess it will narrow the discussion by demonstrating idiomatic cmake 3. Too much cmake 2 still kicks around. I really wish cmake would kill off cmake2-isms, as in, refuse to use them.

According to Jens' https://meetingcpp.com/tl_files/blog/bda/boostdepbargraph.png, System looks the most tractable. I'll see if I can find some hours to do it up, I can guarantee it won't be today nor tomorrow. Maybe tomorrow night after the kids are asleep.

Niall

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there. I think its pretty simple and canonical usage of CMake as it relates to a Boost library. The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple. What would be missing from this for it it to meet expectations of CMake Promotors? Robert Ramey

On 6/17/17 11:42 AM, P F via Boost wrote:

...

Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there. I think its pretty simple and canonical usage of CMake as it relates to a Boost library. The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple. What would be missing from this for it it to meet expectations of CMake Promotors?

* It should not use global `include_directories`.

* Its not necessary to put CMakeLists.txt in every directory with modern cmake.

* There is no installation, and there is no support for `find_package(SafeNumerics)` which can provide a cmake target for downstream user to use. Nor does it provide a cmake target for people to use with `add_subdirectory` either.

* Tests are always built even when the user sets `BUILD_TESTING` to off.

Boost.Hana is much better example of modern cmake.

Thanks for looking at this - the comments above really make me see that even having spend a lot of time trying to figure out CMake - there is still a lot I don't know. I have questions on each point above, but they are not relevant to this thread so I'll move on. I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which. * only needs to run tests * users need only point to the header library. Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal. Robert Ramey

> On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
> 
> On 6/17/17 11:42 AM, P F via Boost wrote:
>>> Hmmm - I would be curious if a CMake enthusiast took a look at the Safe Numerics repo and commented on the CMake files listed there.  I think its pretty simple and canonical usage of CMake as it relates to a Boost library.  The only think I want to change is the existence of some code in a CMake directory which I'll soon eliminate - but all in all it's pretty simple.  What would be missing from this for it it to meet expectations of CMake Promotors?
>> * It should not use global `include_directories`.
>> * Its not necessary to put CMakeLists.txt in every directory with modern cmake.
>> * There is no installation, and there is no support for `find_package(SafeNumerics)` which can provide a cmake target for downstream user to use. Nor does it provide a cmake target for people to use with `add_subdirectory` either.
>> * Tests are always built even when the user sets `BUILD_TESTING` to off.
>> Boost.Hana is much better example of modern cmake.
> 
> Thanks for looking at this - the comments above really make me see that even having spend a lot of time trying to figure out CMake - there is still a lot I don't know.  I have questions on each point above, but they are not relevant to this thread so I'll move on.
> 
> I also looked at Hana usage of CMake.  I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

> 
> * only needs to run tests
> * users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

> 
> Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

...

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

I think it is at minimum relevant, and mostly fair. The argument for using an external non-Boost build system, regardless of which one is the current flavor, is that it is externally supported. And hence no one at Boost needs to write a bunch of code to make use of it for the Boost use case. But if there needs to be a significant amount of code in Boost for the build system the justifications for switching loose considerable appeal. It doesn't matter where the code is. If it's in individual libraries or collected in a common Boost module, it's still effort to maintain comparable to the effort of maintaining b2.

There is many use cases for switching to cmake. One use case is modular building and to have boost export its usage requirements in the form of pkgconfig or cmake find packages. This can also be done using bjam files as well, but there is work that needs to be done to support this. Of course, the fact that Louis has done the work is not fair to compare with non-existent work. Furthermore, the argument is made that by switching to cmake, boost can take advantage of this larger community support to fulfill this work, instead of letting a decade go by on such unfulfilled requests in bjam.

On Jun 18, 2017, at 9:24 AM, Rene Rivera via Boost <boost@lists.boost.org> wrote:

On Sun, Jun 18, 2017 at 12:03 AM, P F <pfultz2@yahoo.com <mailto:pfultz2@yahoo.com>> wrote:

...

On Jun 17, 2017, at 11:14 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

On Sat, Jun 17, 2017 at 10:55 PM, P F via Boost <boost@lists.boost.org> wrote:

...

...

On Jun 17, 2017, at 3:10 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

I think it is at minimum relevant, and mostly fair. The argument for using an external non-Boost build system, regardless of which one is the current flavor, is that it is externally supported. And hence no one at Boost needs to write a bunch of code to make use of it for the Boost use case. But if there needs to be a significant amount of code in Boost for the build system the justifications for switching loose considerable appeal. It doesn't matter where the code is. If it's in individual libraries or collected in a common Boost module, it's still effort to maintain comparable to the effort of maintaining b2.

There is many use cases for switching to cmake. One use case is modular building

Concretely define what "modular building" is.

git clone https://github.com/boostorg/build cd build ./bootstrap.sh b2 install cd .. git clone https://github.com/boostorg/hana cd hana b2 install or with cmake: git clone https://github.com/boost-cmake/bcm cd bcm mkdir build cd build cmake .. cmake --build . --target install cd ../.. git clone https://github.com/boostorg/hana cd hana mkdir build cd build cmake .. cmake --build . --target install

...

and to have boost export its usage requirements in the form of pkgconfig or cmake find packages.

Concretely define what it means to support those.

These files would be generated during installation. I am not sure what more detail you are asking?

...

This can also be done using bjam files as well, but there is work that needs to be done to support this.

True.. But the assumption seems to be that it would easier to do all of the above with cmake. Which I dispute.

That is not my assumption, either.

...

Of course, the fact that Louis has done the work is not fair to compare with non-existent work.

Perhaps it's not fair to compare work that hasn't been defined sufficiently to implement for any build system.

...

Furthermore, the argument is made that by switching to cmake, boost can take advantage of this larger community support to fulfill this work, instead of letting a decade go by on such unfulfilled requests in bjam.

It is unfair to blame the build system for requests that are substantially structural issues with Boost. Issues that would malign any build system that Boost might use.

Yes, the build is not directly at fault, but if boost moved to cmake, there is a much larger community of people who are familiar with cmake and boost that could help work on these structural changes.

On 6/18/17 8:13 AM, Peter Dimov via Boost wrote:

"P F" wrote:

...

git clone https://github.com/boostorg/hana cd hana b2 install

Does anybody actually do this?

Hmmm - what I do is git clone https://github.com/boostorg/hana // into my BOOST_ROOT b2 headers then I'm done. It never occurred to me that that was alien. Actually, even now, I can't think of what I would do instead. It feels completely alien to me. Where

would the headers go? What will happen to the already existing system Boost installation?

What if I want to uninstall? I just would delete $BOOST_ROOT/libs/hana

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

On 19/06/2017 06:50, Andrey Semashev wrote:

`make install` into system directories and similar commands are indeed discouraged (at least, on Linux) because there is typically no `make uninstall`. You can install into a separate subtree though, with the assumption that you can safely delete it afterwards.

autoconf has supported "make uninstall" forever (or sufficiently close to it). Most autoconf "replacements" haven't bothered. But these typically install into separate directories from the package-managed directories anyway (/usr/local/* rather than /usr/*), so they're not hard to get rid of again, as long as developers don't do dumb things. (Which is by no means guaranteed, of course.)

On 6/17/17 8:55 PM, P F via Boost wrote:

...

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.

I agree which is why I am writing cmake modules to help make this more straightforward.

...

* only needs to run tests * users need only point to the header library.

A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.

...

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal.

I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

Hmmm - Now I don't know what the proposal is. I thought it was to replace bjam. I don't know what else it needs to do. I see CMake as an alternative way of building and testing libraries. I don't see this impacting users in any way. I thought I knew what is being proposed but now I don't think I do. Perhaps this proposal should be something more specific than "Moving Boost to CMake". Robert Ramey

On 6/18/17 7:30 AM, P F via Boost wrote:

...

Hmmm - Now I don't know what the proposal is. I thought it was to replace bjam. I don't know what else it needs to do. I see CMake as an alternative way of building and testing libraries. I don't see this impacting users in any way. I thought I knew what is being proposed but now I don't think I do. Perhaps this proposal should be something more specific than "Moving Boost to CMake”.

I believe the proposal was to move to cmake using cmake’s best practices for building, testing, and supporting `find_package`.

LOL - so it seems that neither one of knows what the proposal actually is. I think it's time for the promoters of this proposal to step back and agree on some more specific/concrete proposal that can be discussed in a productive way - probably on a new thread. Probably with a titile like one of the following: a) proposal - Add support for CMake for building boosts and running tests b) proposal - Add support for CMake to make Boost more user friendly by ... c) proposal - add your own here ... And this proposal should start with a succinct goal or motivation Then describe the actions proposed to support the above. It's helpful it describes who would undertake which actions - library maintainers, some Developer, Some other player like the developers of CMake itself, etc. Some sort of plan/description of how this would would proceed - All at once - some proposals might not make sense unless applied to all libraries as a requirement. Others might work as an option for each library. Sorry I can't be more specific - but of course I'm not the one making such a proposal. Robert Ramey

On 6/18/17 9:15 AM, Stefan Seefeld via Boost wrote:

Hi Robert,

It's really sad to see how much effort gets wasted on this list over the years as ambitious people propose one idea or another, but eventually get dragged down by the community's inability to "get their act together" and move in almost any direction, leaving us with the status quo.

LOL - I'm really sympathetic. I often feel the same way. But if you think about it, it really can't be any other way. We each have our own set of problems which are "caused" by something or someone else. The solution is to have that "other" thing get fixed. And this often ends up with a bunch competing and conflicting ideas which an never really be resolved. (BTW - it's not just boost it's everywhere). But we are blessed by self awareness and the ability to engage in introspection. So we can step back and reset and ask the question what the hell are we trying to do anyway. This is sometimes helpful. A different problem is that compromise - which is necessary often takes the form of including everything - which often kills the whole idea. We have to work harder to address that. But as the author of two accepted boost libraries, I can say taht there is no way I could have completed those tasks without collaboration of those on this list, reviewers, testers, bug reporters, infrastructure builders etc. Impossible. I don't know enough - I don't think anyone does. (though I think a goodly number of us think they do - but I doubt they have actually gotten a library into boost). So to keep moving forward we have to find a way to keep this working. I've sort of inherited the role of mailing list nannie from david abrahams. I'm sorry about that - I just can't help it.

> On Jun 18, 2017, at 10:43 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
> 
> On 6/18/17 7:30 AM, P F via Boost wrote:
>>> On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
>>> 
>>> On 6/17/17 8:55 PM, P F via Boost wrote:
>>>>> I also looked at Hana usage of CMake.  I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which.
>>>> I agree which is why I am writing cmake modules to help make this more straightforward.
>>>>> 
>>>>> * only needs to run tests
>>>>> * users need only point to the header library.
>>>> A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)
>>> 
>>> Hmmm - I never felt the need for this.  I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.
>> Much easier to say `cmake --build . --target install` or `install lib` from a package manager then manually figuring out what files need to be copied. Furthermore, this prevents installing the usage requirements, which it is much easier to say `g++ $(pkg-config boost_asio --cflags --libs)` or `target_link_libraries(myLib boost::asio)` then trying to figure out all the compiler and linker flags needed to use asio. A header-only should still provide its usage requirements, because:
>> * It may require linking in other libraries. Although a library is header-only it may depend on non-header-only libraries. This is the case for Boost.Asio, which needs to link in other libraries.
>> * A library may change usage requirements in the future. A library could change from header-only to being built, or it could bring in a new dependency that requires linking in a new library. This would affect all downstream libraries, but if the build scripts are using the usage requirements this will require zero changes to the build scripts.
> 
> Hmmm  - All of this might help the user (though I doubt it in my case, not that that matters).  

There is no reason to doubt that user would find this helpful, otherwise users wouldn’t ask for such features. And it may seem like it doesn’t matter at this point for `safe_numerics`, except if you or one the libraries you depend on decide to use a compiled component this will effect both you and your users.

> But I don't see how it concerns boost library development.  Boost library development is concerned with building libraries and running tests.

And also distribution. Nobody is going to use your library without distribution.

> 
> So it sounds like you're interested in making Boost a more satisfying experience for users of Boost Libraries.  A worthy consideration which I believe many of use would support.  I would support a working FindBoost for example as I use CMake to build ide.  Sounds like you have something in mind like FindBoostSerialization, FindBoostHana, etc.  

No, something like boost_serialization-config.cmake or boost_hana-config.cmake. Find modules are for third-party libraries that don’t support cmake consumers.

> Which might also be interesting - but it has nothing to do with library development.  

It does, because each library knows its usage requirements and when they will change, thus each library should provide that to the users.

> FindBoost can be made to work without boost developers doing anything differently.  Why not make a separate project FindBoostxxx and include all anything you want there.  The you don't have convince anyone to do anything, all you have to do is do it.

This does work currently because cmake developers have reversed-engineered the usage requirements, so I can write something like this in cmake:

find_package(Boost)
target_link_libraries(myLib boost::asio)

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.

On Sun, Jun 18, 2017 at 4:09 PM, P F via Boost <boost@lists.boost.org> wrote:

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is, IMO, a design and implementation defect of cmake. Second.. Why not use something like Conan that doesn't care about what build system your dependencies use and will adjust to the build system you are using for your product? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2017-06-19 1:14 GMT+02:00 Vinnie Falco via Boost <boost@lists.boost.org>:

On Sun, Jun 18, 2017 at 4:05 PM, Rene Rivera via Boost <boost@lists.boost.org> wrote:

...

Why not use...Conan

Conan is great for killing trolls but for generating Visual Studio project and solution files (.vcxproj and .sln)? Not so much.

Conan is not a build system, so I am not sure why it should generate a Visual Studio project and solution. It integrates with any build system, having built-in support for most common ones. If you are using cmake, conan will generate a "conanbuildinfo.cmake" with information about your dependencies in it, you can use in your CMakeLists.txt, and of course generate Visual Studio solutions and projects from your CMakeLists.txt, exactly as you do now. Furthermore, conan is able to provide direct, native integration with Visual Studio. It has helpers that can build VS solutions easily, and it generates "conanbuildinfo.props" files, that can be directly loaded into Visual Studio. Check this blog post for example: http://blog.conan.io/2017/05/11/C-C++-Binary-Package-Management-for-Visual-S... The CMake integration, generating Visual Studio projects is much more widely used, but both approaches are already being actively used in production.

On Sun, Jun 18, 2017 at 6:15 PM, Richard Hodges <hodges.r@gmail.com> wrote:

This is a sorry state of affairs for the worlds most popular c++ library. It should be easy, no, automatic to include boost. After all, c++ without boost is like [insert idiom about useless things here].

I've mentioned this some number of times in the past decade or more.. Using Boost should be as easy as dropping the source code into your project (and hence use your build system) and build as needed for your project. And I've asserted that libraries that don't document how to do that should consider having a bug. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Mon, 2017-06-19 at 07:58 +0100, John Maddock via Boost wrote:

On 19/06/2017 00:41, Rene Rivera via Boost wrote:

...

On Sun, Jun 18, 2017 at 6:15 PM, Richard Hodges <hodges.r@gmail.com> wrote:

...

This is a sorry state of affairs for the worlds most popular c++ library. It should be easy, no, automatic to include boost. After all, c++ without boost is like [insert idiom about useless things here].

I've mentioned this some number of times in the past decade or more.. Using Boost should be as easy as dropping the source code into your project (and hence use your build system) and build as needed for your project.  And I've asserted that libraries that don't document how to do that should consider having a bug.

+1, the vast majority of libraries (that need building) are "just bunch  of source files".  I routinely build them outside of bjam (or anything  else for that matter) because it's easier to include them in Visual  Studio solutions that way - at least for me.

I don't think globbing source files is the problem. The problem is linking in the dependencies and possible compiler flags. 

For whatever its worth as a user who sometimes contributes patches to fix bugs, I don't use the system compiler and instead use scripts to test different builds of internal code (clang, clang with various sanitizers and options, different versions of gcc, etc). This is such a pain with boost build because of the difficulty of automating building multiple copies with custom compilers and flags with the same source tree. In cmake this is easy, you just change some command line flags, something trivial in scripts. In Boost, I think I got it working once using undocumented features after spending several hours looking around at docs, source code(!), and stack overflow. I now automatically just don't use boost libraries that aren't header only. I would rather rewrite code than fight with the build process. That is a bad state of affairs. On Sun, Jun 18, 2017 at 5:15 PM, Richard Hodges via Boost <boost@lists.boost.org> wrote:

"Easier integration with cmake" is. It the only concern. There's also cross-compiling to iOS, android etc etc.

How to do this properly is fully documented in cmake (And provided free of efort with polly) in bjam it's a total black art.

I am always left with the nagging feeling that something is wrong, because despite following the instructions on stack overflow, there is no actual documentation to convince me that all the voodoo in the jam files has received the correct number of sacrificial virgins.

This is a sorry state of affairs for the worlds most popular c++ library. It should be easy, no, automatic to include boost. After all, c++ without boost is like [insert idiom about useless things here].

R

On Mon, 19 Jun 2017 at 01:05, Rene Rivera via Boost <boost@lists.boost.org> wrote:

...

On Sun, Jun 18, 2017 at 4:09 PM, P F via Boost <boost@lists.boost.org> wrote:

...

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that.

Instead

...

each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.

First.. Needing to upgrade cmake to deal with newer releases of Boost is, IMO, a design and implementation defect of cmake.

Second.. Why not use something like Conan that doesn't care about what build system your dependencies use and will adjust to the build system you are using for your product?

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

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

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

On Jun 17, 2017, at 11:30 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

...

2. I am making a new Boost library or I am using Boost trunk source tree. So add_subdirectory(boost/libs/asio EXCLUDE_FROM_ALL), link to boost::asio

No, the `add_subdirectory` is for a superproject. A library will just call `find_package`(which the superproject will override) to get the targets.

You mean dependency. Like boost is for end user programs.

A significant minority of end users will not wish to use find_package() and will strongly prefer to use add_subdirectory(). For example, anyone on Windows will find add_subdirectory() vastly easier going. Anyone who currently integrates Boost into their own build and test config will use add_subdirectory(). Anyone who builds Boost with custom config will use add_subdirectory().

Well written cmake 3 has no problem allowing that. It's now a build driver, any external cmake can load it in and ask it for as much or as little build config as necessary. It's why cmake 3 is so radically better than cmake 2. Stephen did an amazing job in restructuring cmake to be reusable by other cmake. CMakeLists.txt is just a library now, to be consumed by other cmake scripts. If you keep CMakeLists.txt completely free of custom function and macro baggage, your CMakeLists.txt becomes extremely reusable and modular for all other cmake.

Yes cmake supports `add_subdirectory` without needing to changing the project scripts. Only the superproject overrides the `find_package`. That is, I write `MyLib` which depends on Foo, like this using `find_package`(ignoring installation for now): find_package(Foo 2.0 REQUIRED) add_library(MyLib) target_link_libraries(MyLib Foo::Foo) Then if the user would like to build `MyLib` and `Foo` all in the same superprojects they can override `find_package`: set(as_subproject Foo MyLib) macro(find_package) if(NOT "${ARG0}" IN_LIST as_subproject) _find_package(${ARGV}) endif() endmacro() add_subdirectory(Foo) add_subdirectory(MyLib) add_subdirectory(App) In addition you can mix external dependencies and `add_subdirectory`. That is, if Foo depends on zlib, then that could be found with `find_package` instead of being built within the same project. However, a library should *not* avoid calling `find_package` or rely on strange custom logic(like `if(NOT TARGET)`) in order support `add_subdirectory. Each library should be able to be built independently and then we(or the user) overrides `find_package` to support the superproject builds.

...

...

You can create header only library targets and >= 3.5 those work right without bugs. You can create static and dynamic library targets for those libraries which implement those.

We need to generate the cmake config package. And that includes the dependencies. Libraries like Hana can “cheat” and export the targets directly to the cmake config package because it has no dependencies. However, for a library like Boost.Fusion the dependencies will need to be listed a third time in the cmake config.

You don't need to generate the cmake config package. cmake generates the cmake config package using its knowledge of how to build the code. I don't know where you're getting all this complexity from.

A correct implementation doesn't need anybody to "cheat". It should be 100% modern cmake. If anybody needs to cheat, you've done it wrong.

Cmake generates the export targets, however, if a dependency comes from another imported target, cmake will not create those imported targets. Instead they need to be defined with a call to `find_package`. However, in a config cmake package you will use `find_dependency` instead(which is almost the same except it it forwards the correct parameters for EXACT, QUIET and REQUIRED which were passed to the original `find_package` call). So if `MyLib` depends on `Foo`, then the cmake pakcage config would be written like this: include(CMakeFindDependencyMacro) find_dependency(Foo 2.0) include("${CMAKE_CURRENT_LIST_DIR}/MyLibTargets.cmake”) The `find_dependency` is necessary because `MyLib` depends on `Foo::Foo` which would be left undefined without a call to `find_package`(or `find_dependency` in this case). This allows the dependencies and packages to be relocatable, which is important. However, in the case of a library like Hana, that has no dependencies, there is no need to call `find_dependency. Essentially, it would look like this: include("${CMAKE_CURRENT_LIST_DIR}/HanaTargets.cmake”) So instead of having cmake write the targets to a separate file, instead the targets can be written directly to the `HanaConfig.cmake`. This is what I meant by “cheat”. What Hana does is entirely correct and appropriate.

...

...

I would personally suggest a Python script which parses Jamfile.v2 and spits out a CMakeLists.txt. You'd get 80% of Boost.Build easily enough using just this.

We can generate the code with python, which will help with libraries that have lots of dependencies. Although some libraries like Boost.Config is not so simple.

I don't know what you're talking about. cmake tracks dependencies just fine and can export dependencies into things which consume targets.

For every `find_package` used in cmake(that is not a build-dependency) there needs to be a corresponding `find_dependency` call in the cmake package config file. Also, Boost.Config tests are generated from *.ipp files, which is different than other boost libraries, and it adds a little more complexity.

...

...

You just then need to feed everything to the cmake package tooling, again all 100% cmake 3. And you should be done, no cmake innovation needed

The BCM modules aren’t trying to work or redefine the cmake workflow, rather it is tool to help reduce the boilerplate needed to provide cmake support in libraries like boost. Otherwise we will have authors create their own set of functions to make the build scripts more maintainable, and then we will lose consistency among boost libraries.

If there is a single custom function in what is implemented, then it's being done wrong. cmake 3.5 and later comes with substantial runtime facilities obviating the need for macros and custom functions for most end users. Just use what comes built into cmake.

I appreciate all the work you've done with the BCM cmake modules. I respectfully insist that all that is superfluous in a minimum viable cmake 3.5 implementation. I appreciate what you are saying about the boilerplate issue, but if you require cmake 3.5 minimum, I do not believe any significant boilerplate issue should occur.

I disagree, there is still quite a bit of boilerplate. Also, the modules support additional things like pkgconfig.

(Where the difference between mine and your approach stems from is that cmake is scriptable i.e. you can write programs in cmake which run over a source tree and do housekeeping using "cmake -P" (sometimes "ctest -S" is easier/better). These scripts can talk with git and pregenerate boilerplate that in cmake v2 days would be hidden inside macros. They can also install themselves into githooks so they regenerate boilerplate when you do git checkout and so on.

I think code generation on each commit is the wrong way to do this.

A classic boilerplate to generate is lists of source files to save CMakeLists.txt having to specify it.

That is not something BCM tries to do. Authors can decide how they want to manage that. Instead BCM tries to handle the boilerplate between synchronizing the dependencies in the build, cmake package config, linking, and pkgconfig. It can also help ensure that libraries correctly alias the target to easily support superproject builds.

Another classic cmake script is for Appveyor and Travis run per commit as cmake is portable and actually pretty powerful as a programming language.)

So tl;dr; I strongly recommend placing all cmake complexity into runnable scripts which generate .cmake files to be include()d to avoid boilerplate, and keep the CMakeLists.txt etc completely free of any custom macros or functions. This greatly reduces the learning curve for library developers, keeps the cmake clean for end users to import into their cmake, and of course keeps build and configure times very quick.

Niall

-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

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

Because cmake's package management (particularly when used with hunter) correctly manages dependencies for cross-compiled environments and for all toolchains. When using the same code base for 6 different compile targets as I do (unix, mac, windows, iOS, android, emscripten) it's a godsend. On Mon, 19 Jun 2017 at 10:58, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having

On Sat, Jun 17, 2017 at 3:36 PM, P F via Boost <boost@lists.boost.org> wrote: pkgconfig would be helpful as well.

I don't really get find_package and pkgconfig etc.

I use package management to install the dependencies I need. I then include and link to the stuff I need. It'd be nice if the linking was automatic like it is on MSVC but okay.

Why does one need all kinds of extra complexity in every single make file for things like find_package or pkgconfig?

-- Olaf

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

On Jun 19, 2017, at 3:58 AM, Olaf van der Spek via Boost <boost@lists.boost.org> wrote:

On Sat, Jun 17, 2017 at 3:36 PM, P F via Boost <boost@lists.boost.org> wrote:

...

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having pkgconfig would be helpful as well.

I don't really get find_package and pkgconfig etc.

I use package management to install the dependencies I need. I then include and link to the stuff I need. It'd be nice if the linking was automatic like it is on MSVC but okay.

Why does one need all kinds of extra complexity in every single make file for things like find_package or pkgconfig?

I find writing something like `g++ $(pkgconfig boost_asio --cflags —libs) foo.cpp` much easier to write. In fact, I would need some investigating to know what flags I need. Other users would like boost to support pkgconfig as well as there are tickets open for this. Almost the same applies for `find_package` in cmake as well. It doesn’t add too much complexity. The files for pkgconfig are a simple text format, and for find_package, cmake can already generate the code the exported target. What is different is that all the dependencies between boost libraries are explicit. So the `boost_core-config.cmake` look like this: include(CMakeFindDependencyMacro) find_dependency(boost_config) find_dependency(boost_assert) # Include the targets generated by cmake include("${CMAKE_CURRENT_LIST_DIR}/boost_core-targets.cmake”) And then targets file is generate by calling `install(EXPORT boost_core-targets FILE FooTargets.cmake DESTINATION lib/cmake/boost_core)` in the main CMakeLists.txt. I actually wrote BCM to help reduce this boilerplate, here: http://bcm.readthedocs.io/en/latest/ However, I planning to refactor this from feedback I got.

On Mon, 2017-06-19 at 18:43 +0200, Olaf van der Spek wrote:

On Mon, Jun 19, 2017 at 5:14 PM, P F <pfultz2@yahoo.com> wrote:

...

...

On Jun 19, 2017, at 3:58 AM, Olaf van der Spek via Boost <boost@lists.bo ost.org> wrote:

On Sat, Jun 17, 2017 at 3:36 PM, P F via Boost <boost@lists.boost.org> wrote:

...

It would be nice to not just support cmake, but pkgconfig as well. There are many times I need to use boost in non-cmake projects, so having pkgconfig would be helpful as well.

I don't really get find_package and pkgconfig etc.

I use package management to install the dependencies I need. I then include and link to the stuff I need. It'd be nice if the linking was automatic like it is on MSVC but okay.

Why does one need all kinds of extra complexity in every single make file for things like find_package or pkgconfig?

I find writing something like `g++ $(pkgconfig boost_asio --cflags —libs) foo.cpp` much easier to write. In fact, I would need some investigating to know what flags I need. Other users would like boost to support pkgconfig as well as there are tickets open for this. Almost the same applies for `find_package` in cmake as well.

`g++ foo.cpp` would be even easier.. but Linux still doesn't support auto-linking like GCC AFAIK.

Even if auto-link would work, it would fail to find the headers for user installations. I could hard-code the include path, but this makes the build not-relocatable to another machine. I could add a custom variable like `BOOST_ROOT` but this complicates the build environment.  For proprietary builds, you can get away with a lot. You can require the developers to put the dependency in a certain folder or set all these build flags.  However, for open-source it is very different because the users will be building the product as well. They may have different build envirnomnents, they may put all their dependencies in /opt/foo or they may spread it out among different folders, or they may be cross-compiling so they need to ignore the host dependencies.  Boost should definitely support these open-source workflows, as many other open-source libraries do.

a user-config.jam has to exist in one of several defined places, $HOME or $BOOST_BUILD_PATH. This is incompatible with wanting a scripted environment. Building everything in one go prohibits you from using a separate install prefix for each compiler, which is needed to build a separate root directory for each tool chain you might have. With CMake I literally just set the Compiler and compiler flags from the command line (-DCMAKE_CXX_COMPILER=whatever, etc). With boost, I'm not even sure how to do it. I think there is some undocumented feature to let you put a custom jam file in some random directory and then use some undocumented flag to somehow point b2 to use that directory to look for your jam file/build in. So I think it might somehow be possible to write a script to write a jam file for each compiler I want to use in a build directory and somehow do an out of tree build for boost in that directory pointing at that jam file. I don't know the magic steps to invoke for it. If it exists its certainly not documented. I test an internal code base with > 9 compiler configurations(from source) for the entire dependency chain. Just adding features to a jam manually is not an option; everything should be automateable. Anything not automateable gets broken. On Mon, Jun 19, 2017 at 12:28 PM, Daniel James via Boost <boost@lists.boost.org> wrote:

On 19 June 2017 at 01:53, Gary Furnish via Boost <boost@lists.boost.org> wrote:

...

For whatever its worth as a user who sometimes contributes patches to fix bugs, I don't use the system compiler and instead use scripts to test different builds of internal code (clang, clang with various sanitizers and options, different versions of gcc, etc). This is such a pain with boost build because of the difficulty of automating building multiple copies with custom compilers and flags with the same source tree. In cmake this is easy, you just change some command line flags, something trivial in scripts. In Boost, I think I got it working once using undocumented features after spending several hours looking around at docs, source code(!), and stack overflow. I now automatically just don't use boost libraries that aren't header only. I would rather rewrite code than fight with the build process. That is a bad state of affairs.

That's odd, that's one thing I've always found easier with boost build than any other build system. You add a target to your user-config.jam, such as:

using gcc : sanitize : g++ -fsanitize=address ;

Then run the build using something like 'b2 gcc-sanitize'. I think there's some way of specifying flags at the command line, but I find it's easier just to set up a number of configurations in the configuration file. So when developing unordered, if I want to run the insert tests, I might do something like this:

cd libs/unordered/test b2 -q insert_tests gcc gcc-std11 clang clang-std14

I have no idea how to do the same thing with cmake. As far as I'm aware with cmake you have to set up multiple build directories for each variant of each project. I've found it a real pain for building projects like libc++.

Just to make it clear, I'm far from an expert in boost build, and struggle with many other aspects. But I've never found cmake to be the land of milk and honey that I hear so much about. I'm also more than a bit fed up of cleaning up after other people's grand projects.

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

This option *really* needs to be on "http://www.boost.org/build/doc/html/bbv2/overview/configuration.html" and that cmake file is the most amazing thing ever. Why can't we get something like that made official at least? On Mon, Jun 19, 2017 at 3:38 PM, paul <pfultz2@yahoo.com> wrote:

On Mon, 2017-06-19 at 14:57 -0600, Gary Furnish via Boost wrote:

...

a user-config.jam has to exist in one of several defined places, $HOME or $BOOST_BUILD_PATH. This is incompatible with wanting a scripted environment. Building everything in one go prohibits you from using a separate install prefix for each compiler, which is needed to build a separate root directory for each tool chain you might have. With CMake I literally just set the Compiler and compiler flags from the command line (-DCMAKE_CXX_COMPILER=whatever, etc).

In general in cmake, I use a toolchain file for each toolchain I need to target. This way I don't need to pass a bunch flags when I invoke cmake. The user-config.jam is similiar.

...

With boost, I'm not even sure how to do it. I think there is some undocumented feature to let you put a custom jam file in some random directory

You can pass the user-config.jam into b2:

b2 --user-config=<path-to-user-config.jam-fil>

...

and then use some undocumented flag to somehow point b2 to use that directory to look for your jam file/build in. So I think it might somehow be possible to write a script to write a jam file for each compiler I want to use in a build directory and somehow do an out of tree build for boost in that directory pointing at that jam file. I don't know the magic steps to invoke for it. If it exists its certainly not documented. I test an internal code base with > 9 compiler configurations(from source) for the entire dependency chain. Just adding features to a jam manually is not an option; everything should be automateable. Anything not automateable gets broken.

Actually, you might be interested in this cmake file:

https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake

You can drop this in the top-level boost directroy and rename it to 'CMakeLists.txt', and it will under-the-hood generate a user-config.jam file with the setting from the cmake toolchain, and then build boost using this user-config.jam file.

...

On Mon, Jun 19, 2017 at 12:28 PM, Daniel James via Boost <boost@lists.boost.org> wrote:

...

On 19 June 2017 at 01:53, Gary Furnish via Boost <boost@lists.boost.org> wrote:

...

For whatever its worth as a user who sometimes contributes patches to fix bugs, I don't use the system compiler and instead use scripts to test different builds of internal code (clang, clang with various sanitizers and options, different versions of gcc, etc). This is such a pain with boost build because of the difficulty of automating building multiple copies with custom compilers and flags with the same source tree. In cmake this is easy, you just change some command line flags, something trivial in scripts. In Boost, I think I got it working once using undocumented features after spending several hours looking around at docs, source code(!), and stack overflow. I now automatically just don't use boost libraries that aren't header only. I would rather rewrite code than fight with the build process. That is a bad state of affairs.

That's odd, that's one thing I've always found easier with boost build than any other build system. You add a target to your user-config.jam, such as:

using gcc : sanitize : g++ -fsanitize=address ;

Then run the build using something like 'b2 gcc-sanitize'. I think there's some way of specifying flags at the command line, but I find it's easier just to set up a number of configurations in the configuration file. So when developing unordered, if I want to run the insert tests, I might do something like this:

cd libs/unordered/test b2 -q insert_tests gcc gcc-std11 clang clang-std14

I have no idea how to do the same thing with cmake. As far as I'm aware with cmake you have to set up multiple build directories for each variant of each project. I've found it a real pain for building projects like libc++.

Just to make it clear, I'm far from an expert in boost build, and struggle with many other aspects. But I've never found cmake to be the land of milk and honey that I hear so much about. I'm also more than a bit fed up of cleaning up after other people's grand projects.

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

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

On 19 June 2017 at 22:38, paul via Boost <boost@lists.boost.org> wrote:

Actually, you might be interested in this cmake file:

https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake

You can drop this in the top-level boost directroy and rename it to 'CMakeLists.txt', and it will under-the-hood generate a user-config.jam file with the setting from the cmake toolchain, and then build boost using this user-config.jam file.

It looks like this a number of caveats: * It doesn't import any of the targets generated by the boost project. Ideally they should be imported along with their usage requirements. * It doesn't deal with the dependencies of Boost libraries, be it where to find libc and libstdc++ (important when cross-compiling) or libz, python and ICU. * It doesn't deal properly with compilation and link flags, though it tries to

On 6/19/2017 2:28 PM, Daniel James via Boost wrote:

On 19 June 2017 at 01:53, Gary Furnish via Boost <boost@lists.boost.org> wrote:

...

For whatever its worth as a user who sometimes contributes patches to fix bugs, I don't use the system compiler and instead use scripts to test different builds of internal code (clang, clang with various sanitizers and options, different versions of gcc, etc). This is such a pain with boost build because of the difficulty of automating building multiple copies with custom compilers and flags with the same source tree. In cmake this is easy, you just change some command line flags, something trivial in scripts. In Boost, I think I got it working once using undocumented features after spending several hours looking around at docs, source code(!), and stack overflow. I now automatically just don't use boost libraries that aren't header only. I would rather rewrite code than fight with the build process. That is a bad state of affairs.

That's odd, that's one thing I've always found easier with boost build than any other build system. You add a target to your user-config.jam, such as:

using gcc : sanitize : g++ -fsanitize=address ;

Then run the build using something like 'b2 gcc-sanitize'.

I have been doing something similar. But according to the Boost Build docs ( http://www.boost.org/build/doc/html/bbv2/reference/tools.html#bbv2.reference... ) the "sanitize" in your example is the gcc version. So I might have the equivalent of: using gcc : 6.3sanitize : g++ : -fsanitize=address ; and I no doubt delude myself in thinking that when I might run 'b2 gcc-6.3sanitize' that Boost Build actually checks that the version I am using is gcc 6.3. In the docs it does not really say what Boost Build actyally does with that 'version' in the using gcc rule.

I think there's some way of specifying flags at the command line

'b2 gcc-sanitize cxxflags=-fsanitize=address' should also work.

, but I find it's easier just to set up a number of configurations in the configuration file. So when developing unordered, if I want to run the insert tests, I might do something like this:

cd libs/unordered/test b2 -q insert_tests gcc gcc-std11 clang clang-std14

I agree with you but I am pretty sure the problem is end-users trying to understand that you can do these things with Boost Build. It is not so much that the information is not in the Boost Build docs as it is that the docs themselves are not geared nearly well enough for the beginning end-user of Boost Build to make it easy for them to understand what you can do with it.

I have no idea how to do the same thing with cmake. As far as I'm aware with cmake you have to set up multiple build directories for each variant of each project. I've found it a real pain for building projects like libc++.

Just to make it clear, I'm far from an expert in boost build, and struggle with many other aspects. But I've never found cmake to be the land of milk and honey that I hear so much about. I'm also more than a bit fed up of cleaning up after other people's grand projects.

On Fri, Jun 16, 2017 at 9:45 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

On 6/16/17 4:44 PM, David Sankel via Boost wrote:

I was going to make an more elaborate counter proposal here but got carried away on another thread an included it there.

Why don't you cut down your proposal to something simpler and actually doable.

I don't think what I'm suggesting is overly bold. We can do this thing. [Reforming large code bases is my day job]

What would you think of the following:

Proposal:

a) Permit Boost Library authors to sprinkle CMakeList.txt files whereever they want in the directories of their own libraries.

To be clear, this is already allowed.

b) Create a directory in boost-root/tools/.... where CMake enthusiasts can put their macros and any other needed stuff of their choosing.

This would yield the following benefits.

a) This should be enough for any library author to implement CMake support for his library.

b) it's non-intrusive. It would not conflict with anything currently in boost.

c) it would permit "Boost/CMake" to evolve at it's own pace without causing havoc among any innocent victims.

d) This would be very simple to do - I don't know that it even requires any decision by anyone at all. I've included CMakeList.txt files in the serialization library for years and no one has objected. I think you should just encourage library authors to do this. You might offer to help them if you want by providing useful macros, a working FindBoost, documentation with suggestions and instructions. I made the Boost Library Incubator with large sections of advice for aspiring boost library authors. I didn't recommend Bjam support as it's not needed for review (and I actually don't like bjam). I recommended CMake and spend a good amount of text explaining it in the context of making a boost like library. I learned that a) CMake isn't nearly as good as people think it is and b) It can be made to work. If you want to improve and maintain that section, I would be very, very pleased to hand it over to you.

Just to summarize:

a) Encourge library authors to include CMakeLists.txt file in their directories. If some committee wants to complain about it, we'll deal with it then.

b) Create helpful information for library authors that want to do this. I've got a good place for you to do it.

Sit back and watch your idea catch fire

:) I don't dislike this idea, but I think moving all of Boost to CMake is a big step that we *can* and *should* do. The first milestone is the most important one in my proposal.

On Fri, Jun 16, 2017 at 9:45 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

Just to summarize:

a) Encourge library authors to include CMakeLists.txt file in their directories. If some committee wants to complain about it, we'll deal with it then.

b) Create helpful information for library authors that want to do this. I've got a good place for you to do it.

Sit back and watch your idea catch fire

:) I don't dislike this idea, but I think moving all of Boost to CMake is a big step that we *can* and *should* do. I disagree. While I applaud your intentions, I think you would do a huge disservice to project maintainers: As Boost.Python maintainer I'm already receiving lots of bug reports about issues with the build system, most of which I have no clue how to resolve, given Boost.Build's often cited complexities. If you add support for a second build system

On 17.06.2017 00:34, David Sankel via Boost wrote: that I don't know anything about, how likely do you think I am to be able to help my user base ? What we need is for project maintainers to be able to pick tools *they* understand so they can operate more autonomously. (And for avoidance of doubt: If their user base asks for a specific tool, it's of course fine for them to decide to support that. But it shouldn't be for any central Boost authority to decide top-down what is best for all projects !) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Sat, Jun 17, 2017 at 12:27 AM, P F <pfultz2@yahoo.com> wrote:

...

On Jun 16, 2017, at 6:44 PM, David Sankel via Boost < boost@lists.boost.org> wrote:

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback.

The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility.

* To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake.

Find modules are only for third-party libraries. Boost should only provide config packages, and then update cmake’s FindBoost to use boost’s cmake config packages.

...

A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this.

Although, somewhat outdated, and incorrect in places, this repo has an example of building boost with proper cmake support:

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

However, I find this brittle and error-prone. Here’s an example of cmake for Boost.Fusion:

https://github.com/boost-cmake/boost-cmake/blob/master/ listsfiles/libs/fusion/CMakeLists.txt

This doesn’t even handle fusion's dependencies, and it is a little incorrect.

I have been working on cmake modules to handle this, but I am in the process of refactoring it, here:

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

One way the Boost.Fusion could be written is like this using the modules to generate the cmake package config:

bcm_setup_version(VERSION ${BOOST_VERSION})

find_package(boost_config) find_package(boost_core) find_package(boost_function_types) find_package(boost_functional) find_package(boost_mpl) find_package(boost_preprocessor) find_package(boost_static_assert) find_package(boost_tuple) find_package(boost_type_traits) find_package(boost_typeof) find_package(boost_utility)

add_library(boost_fusion INTERFACE) add_library(boost::fusion ALIAS boost_fusion) set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

target_link_libraries(boost_fusion INTERFACE boost::config boost::core boost::function_types boost::functional boost::mpl boost::preprocessor boost::static_assert boost::tuple boost::type_traits boost::typeof boost::utility )

bcm_install_targets(TARGETS boost_fusion INCLUDE include) bcm_auto_export(TARGETS boost_fusion DEPENDS PACKAGE boost_config PACKAGE boost_core PACKAGE boost_function_types PACKAGE boost_functional PACKAGE boost_mpl PACKAGE boost_preprocessor PACKAGE boost_static_assert PACKAGE boost_tuple PACKAGE boost_type_traits PACKAGE boost_typeof PACKAGE boost_utility )

However, with dependencies this is not maintainable. But perhaps a `bcm_boost_depends` can handle this, like this:

bcm_setup_version(VERSION ${BOOST_VERSION})

add_library(boost_fusion INTERFACE) add_library(boost::fusion ALIAS boost_fusion) set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

bcm_boost_depends(boost_fusion INTERFACE boost_config boost_core boost_function_types boost_functional boost_mpl boost_preprocessor boost_static_assert boost_tuple boost_type_traits boost_typeof boost_utility )

bcm_install_targets(TARGETS boost_fusion INCLUDE include) bcm_auto_export(TARGETS boost_fusion)

This is the direction I would like to take the modules, and I think this is much more maintainable. Code repetition is not good, and just boost has innovated C++, I see no reason it couldn’t help innovate cmake. Especially, since these modules do no stray from what standard cmake does.

I'd rather not tie cmakification of Boost to innovating CMake, at least not at the outset. I think you have some good ideas in your bcm library, but I'd like to see wider industry adoption before switching Boost to them. I don't like the risk involved.

...

* There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require all the libraries to be built together. I don’t think libraries individually can provide components.

It doesn't require all the libraries to be built together and, yes, libraries can provide components. See this talk: https://www.youtube.com/watch?v=3eH4hMKl7XE

...

* We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake.

Each library should provide its own package of the form `find_package(boost_*)`, and the we can update the cmake to search for those components first and then fallback on the guessing games.

Hrm. Maybe.

...

I see this progressing with several milestones.

1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution

Sans circular dependencies. As libraries which have circular dependencies will always have to be built with the entire distribution, but hopefully having modularing building might push authors to fix the cycles.

Yeah, sans circular dependencies.

...

and all the 'FindBoost' functionality mentioned above would be incorporated.

Wouldn’t we need to update `FindBoost` in cmake so this would work?

No, I don't think so.

On Sat, Jun 17, 2017 at 1:47 AM, P F <pfultz2@yahoo.com> wrote:

On Jun 16, 2017, at 11:51 PM, David Sankel <camior@gmail.com> wrote:

On Sat, Jun 17, 2017 at 12:27 AM, P F <pfultz2@yahoo.com> wrote:

...

...

On Jun 16, 2017, at 6:44 PM, David Sankel via Boost < boost@lists.boost.org> wrote:

...

...

* There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require all the libraries to be built together. I don’t think libraries individually can provide components.

It doesn't require all the libraries to be built together and, yes, libraries can provide components. See this talk: https://www.youtube.com/ watch?v=3eH4hMKl7XE

Sorry, that was worded poorly. Rather a library can not add additional components to a previously installed library(not without some strange hackery).

Ah, I see what you mean now. I didn't mean to imply we should support that use case.

On Jun 17, 2017, at 6:08 AM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

P F wrote:

...

bcm_setup_version(VERSION ${BOOST_VERSION})

When I see this my first thought is always "where do the bcm_ macros come from”?

Ideally, we should strive for libraries to work standalone.

Sorry, I skipped over that part. The bcm_ macros are another boost library that would be installed and found with `find_package`. I was just trying to transform the code I linked to, but ideally, it would written like this: find_package(BCM) find_package(boost_config) # Use main boost version version bcm_setup_version(VERSION ${BOOST_CONFIG_VERSION}) add_library(boost_fusion INTERFACE) add_library(boost::fusion ALIAS boost_fusion) set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion) bcm_boost_depends(boost_fusion INTERFACE boost_config boost_core boost_function_types boost_functional boost_mpl boost_preprocessor boost_static_assert boost_tuple boost_type_traits boost_typeof boost_utility ) bcm_install_targets(TARGETS boost_fusion INCLUDE include) bcm_auto_export(TARGETS boost_fusion)

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

On Jun 17, 2017, at 2:11 AM, Klemens Morgenstern via Boost <boost@lists.boost.org> wrote:

I am dead set against that. CMake is inferior to boost.build and it's only popular for the lack of alternatives. Boost.build could be one (I use it in my projects outside of boost) but it a steep learning curve and is not distributed outside of boost. But even the syntax is less horrible than the CMake one in my opinion.

CMake's syntax is verbose, which makes it much more friendly to pickup. Bjam’s syntax is too terse with too many weird quirks that most authors just copy and paste code.

I do think CMake is broken in it's core, because it doesn't build but create a description (i.e. makefile or similar). And in order to change that I have to clear the cache and reconstruct it. Boost.build on the other hand works like a charm if I have a proper build description and write `b2 toolset=gcc toolset=msvc` - it will build both and test on both without any conflicts.

You would just create two separate build trees for each configuration. I don’t see how that makes CMake broken.

I think we should definitely keep boost.build around, if only to have it's concepts (as in meta-targets) in a working build-system. I also don't think CMake will be around forever, it's a deficient solution.

A lot of autotools projects are moving to cmake. I don’t see them moving the Boost.Build. Boost.Build doesn’t have the support that cmake does.

As ist boost.build, but boost.build gets the job done for boost. I don't see the point of moving from one deficient tool to a worse one, just because everybody seems to be using it.

I don’t think it does get the job done. Some boost libraries do more extensive testing in cmake than in the Boost.Build because it doesn’t get the job done. Some libraries have auto-generated tests and files because Boost.Build doesn’t get the job done. Even more so, downstream projects have to reverse engineer the dependencies because Boost.Build doesn’t get the job done.

On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:

Are you talking about things like this: https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake

Boost.Build implementation: https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

Hey!!! I might have to steal that :)

On Sat, Jun 17, 2017 at 9:45 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

Vinnie Falco wrote:

...

On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:

...

Are you talking about things like this: https://github.com/boostorg/hana/blob/master/cmake/TestHeaders.cmake

Boost.Build implementation: https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

Hey!!! I might have to steal that :)

Might not we all?

I guess Paul is right.. B2 syntax is terse. But not too terse ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

AMDG On 06/17/2017 10:45 AM, Vinnie Falco via Boost wrote:

On Sat, Jun 17, 2017 at 7:37 AM, Steven Watanabe via Boost <boost@lists.boost.org> wrote:

...

Boost.Build implementation: https://github.com/boostorg/units/blob/develop/test_headers/Jamfile.v2

We have the sources to bjam why can't we just turn this into a one-line rule?

For example, this says that test.cpp should compile:

compile test.cpp

Can we just have

compile-header test.hpp

And have bjam add the bits to define a main() and include test.hpp for us?

It's certainly possible if there's enough demand. The main issue for generalization is the test target name. It needs to a) be human readable and writable, b) not be excessively long, and c) not cause collisions (headers with the same name in different directories are normal) In Christ, Steven Watanabe

Le 18.06.17 à 21:05, Louis Dionne via Boost a écrit :

Boost - Dev mailing list wrote

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the discussions in this thread, it seems like people are getting caught into the trap of discussing the specifics of how we would implement a proper CMakeLists.txt file and so on. I think this is completely missing the point. What we need is to acknowledge that the current situation of supporting Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system

This, I think is our real problem. The discussion is not about whether it's better for Boost library developers to use Boost.Build, CMake, or Bazel for that matter. It's about what's best our users, who GREATLY outnumber us. And given that CMake is the de-facto standard, the best way to help our users is to provide easy integration of Boost with that build system (however that happens).

It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority. This has become clear through years of anecdotal evidence (such as speaking to people at conferences). Based on this and previous failed attempts, I think it is unlikely that we'll be able to make a decision based solely on discussion on this list, and my opinion is that a top-down decision is required to make something (anything) happen, like for the Git modularization.

That being said, I would like to propose an alternative route that is softer than David's to see what people think. I still think that David's proposal is better, but if that was uncontroversial enough, perhaps this could get the ball rolling and we could go from there (and provide some relief to our users in the meantime).

The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library. This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake. This would not make Boost easier to build, but once built and installed, it would at least be trivial to use _properly_ from a CMake project. This does not require changing the build system of existing libraries to CMake.

Regards, Louis

I am totally for a better support of CMake, and what you suggest is ok to me. However (and since the topic is already very huge), maybe I missed some elements. This is usually what I do: 1. I build boost using bjam and install it in some folder 2. in "my_other_project" that uses cmake, I just specify -DBOOST_ROOT=/myboostinstallfolder and everything works like a charm. This is something I always did and it always worked, I do not see any strong limitation on it. So when you say "properly", does it mean the support the user gets in case of failure? or for maintaining his own configuration for having FindBoost running ok? Does this means that, all the problems we are facing and trying to solve in this thread are due to the proper integration of some static or shared libraries installed in some path, and users not being able to import those in their own cmake project? (because FindBoost does an ok job, as does FindGoogleTest, FindCUDA, etc etc). Thanks, Raffi

On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:

Boost - Dev mailing list wrote

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the discussions in this thread, it seems like people are getting caught into the trap of discussing the specifics of how we would implement a proper CMakeLists.txt file and so on. I think this is completely missing the point. What we need is to acknowledge that the current situation of supporting Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system

This, I think is our real problem. The discussion is not about whether it's better for Boost library developers to use Boost.Build, CMake, or Bazel for that matter. It's about what's best our users, who GREATLY outnumber us. And given that CMake is the de-facto standard, the best way to help our users is to provide easy integration of Boost with that build system (however that happens).

It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority. This has become clear through years of anecdotal evidence (such as speaking to people at conferences). Based on this and previous failed attempts, I think it is unlikely that we'll be able to make a decision based solely on discussion on this list, and my opinion is that a top-down decision is required to make something (anything) happen, like for the Git modularization.

That being said, I would like to propose an alternative route that is softer than David's to see what people think. I still think that David's proposal is better, but if that was uncontroversial enough, perhaps this could get the ball rolling and we could go from there (and provide some relief to our users in the meantime).

The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library. This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation.

This would not make Boost easier to build, but once built and installed, it would at least be trivial to use _properly_ from a CMake project. This does not require changing the build system of existing libraries to CMake.

Regards, Louis

On Sun, Jun 18, 2017 at 4:03 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:

Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation.

+1. I'm interested in the [typical] Boost header-only library case: - The CMakeLists.txt for building its tests - The .cmake file for locating the library - The consumption of the library in a user's CMakeLists I have a guess ( based on my fairly basic usage of CMake) that at least #3 there should be simple (i.e. would it involve more than adding to include_directories or target_include_directories?). Glen

Glen Fernandes wrote:

+1. I'm interested in the [typical] Boost header-only library case: - The CMakeLists.txt for building its tests - The .cmake file for locating the library - The consumption of the library in a user's CMakeLists

I have a guess ( based on my fairly basic usage of CMake) that at least #3 there should be simple (i.e. would it involve more than adding to include_directories or target_include_directories?).

In principle, neither should be needed, only target_link_libraries( target Boost::Whatever ). The usage requirements of Boost::Whatever would add the include directory (and its dependencies would transitively add their include directories.)

On Jun 18, 2017, at 3:03 PM, Edward Diener via Boost <boost@lists.boost.org> wrote:

On 6/18/2017 3:05 PM, Louis Dionne via Boost wrote:

...

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. [...] FWIW, I support this (or something very similar). Reading some of the discussions in this thread, it seems like people are getting caught into the

Boost - Dev mailing list wrote trap of discussing the specifics of how we would implement a proper CMakeLists.txt file and so on. I think this is completely missing the point. What we need is to acknowledge that the current situation of supporting Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system This, I think is our real problem. The discussion is not about whether it's better for Boost library developers to use Boost.Build, CMake, or Bazel for that matter. It's about what's best our users, who GREATLY outnumber us. And given that CMake is the de-facto standard, the best way to help our users is to provide easy integration of Boost with that build system (however that happens). It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority. This has become clear through years of anecdotal evidence (such as speaking to people at conferences). Based on this and previous failed attempts, I think it is unlikely that we'll be able to make a decision based solely on discussion on this list, and my opinion is that a top-down decision is required to make something (anything) happen, like for the Git modularization. That being said, I would like to propose an alternative route that is softer than David's to see what people think. I still think that David's proposal is better, but if that was uncontroversial enough, perhaps this could get the ball rolling and we could go from there (and provide some relief to our users in the meantime). The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library. This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake.

Please give a specific example of what this XYZConfig.cmake module entails ? For a header-only library ? For a built library ? For running tests ? For creating documentation ? Along with some sort of decent explanation of what is going on in each situation.

I think Daniel Pfeifer “Effective CMake” talk gives a good overview how this can be done in cmake. Of course, doing this outside of cmake would be a little more work, but probably could be built-in to boost build(which can handle the heavy lifting).

Boost - Dev mailing list wrote

On Sun, Jun 18, 2017 at 12:05 PM, Louis Dionne via Boost <

boost@.boost

> wrote:

...

It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority.

You mean the minority that spend countless hours per week maintaining Boost, including libraries they did not author?

Yes. I'm not making any statement about the value of the contributions of an individual or group of individuals to Boost (in particular, I'm not trying to diminish anyone's contribution). I'm stating that some people have a biased view that is not shared by the majority of people using Boost, and this group of people is over represented on this list. If we're not careful about that, we could make decisions that are bad for our users (and I think we sometimes do). -- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.

...

The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library. This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake. This would not make Boost easier to build, but once built and installed, it would at least be trivial to use _properly_ from a CMake project. This does not require changing the build system of existing libraries to CMake.

This seems more sensible, but adding a guideline won't do anything. Someone needs to volunteer to create the pull requests, and maintain it in the future.

Sorry, the original message should have said "add to the Boost library REQUIREMENTS", not GUIDELINES. Requirements are actionable, guidelines are not. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Jun 18, 2017, at 2:05 PM, Louis Dionne via Boost <boost@lists.boost.org> wrote:

Boost - Dev mailing list wrote

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. [...]

FWIW, I support this (or something very similar). Reading some of the discussions in this thread, it seems like people are getting caught into the trap of discussing the specifics of how we would implement a proper CMakeLists.txt file and so on. I think this is completely missing the point. What we need is to acknowledge that the current situation of supporting Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system

This, I think is our real problem. The discussion is not about whether it's better for Boost library developers to use Boost.Build, CMake, or Bazel for that matter. It's about what's best our users, who GREATLY outnumber us. And given that CMake is the de-facto standard, the best way to help our users is to provide easy integration of Boost with that build system (however that happens).

It is also worth noting that people on this list that oppose vocally are Boost library developers or folks with deep involvement/knowledge of Boost.Build, which is a very small minority. This has become clear through years of anecdotal evidence (such as speaking to people at conferences). Based on this and previous failed attempts, I think it is unlikely that we'll be able to make a decision based solely on discussion on this list, and my opinion is that a top-down decision is required to make something (anything) happen, like for the Git modularization.

That being said, I would like to propose an alternative route that is softer than David's to see what people think. I still think that David's proposal is better, but if that was uncontroversial enough, perhaps this could get the ball rolling and we could go from there (and provide some relief to our users in the meantime).

The proposal is to add to the Boost library guidelines the requirement that a XYZConfig.cmake module be provided with the installation of any Boost.XYZ library.

Or rather `boost_xyz-config.cmake` for each Boost.Xyz. The reason for this is: * The `-config.cmake` is case-insensitive * it matches the library name(ie find_package(boost_system) and find_library(LIB boost_system)) * It follows the boost guildelines to have all files be lowercase

This module would simply export the proper CMake targets, which would solve the problem of integrating Boost with a CMake-based build system and would remove the need for the custom FindBoost support in CMake. This would not make Boost easier to build, but once built and installed, it would at least be trivial to use _properly_ from a CMake project. This does not require changing the build system of existing libraries to CMake.

Although I am not following the proposal. Are you suggesting that the Boost.Build generate these files? Or that we move to cmake to build and test, and we require the libraries to install the config files?

Regards, Louis

-- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.

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

On Jun 18, 2017, at 4:09 PM, Louis Dionne via Boost <boost@lists.boost.org> wrote:

...

Or rather `boost_xyz-config.cmake` for each Boost.Xyz. The reason for this is:

* The `-config.cmake` is case-insensitive * it matches the library name(ie find_package(boost_system) and find_library(LIB boost_system)) * It follows the boost guildelines to have all files be lowercase

Sure, anything's fine by me. As long as we settle on something that's blessed by CMake experts (e.g. Stephen Kelly and Daniel Pfeifer), I'm on board.

...

Although I am not following the proposal. Are you suggesting that the Boost.Build generate these files? Or that we move to cmake to build and test, and we require the libraries to install the config files?

I intentionally left it unspecified how these files would be generated and installed. All that I care (in the scope of this sub-proposal) is that they are installed when Boost is installed, so that I can use the targets from CMake without jumping through hoops or relying on the incomplete FindBoost package provided with CMake.

But the question is who will implement it, and how will they be tested?

...

I intentionally left it unspecified how these files would be generated and installed.

What is actionable in your proposal then? What is it you suggest we - by this I mean library developers, who the library guidelines target - actually do?

What's actionable is that if the Boost library requirements contain this, you'll have to go implement it in your own library. There you go, now we've taken care of all the maintained libraries. For the unmaintained ones, we have a community maintenance team that has commit privilege to them, and I'm sure we can find people to submit pull requests. Let me get the ball rolling; I volunteer to do the work for Boost.MPL and Boost.ConceptCheck. There's now 8 libraries remaining: [ ] Boost.DateTime [ ] Boost.DisjointSet [ ] Boost.DynamicBitset [ ] Boost.Format [ ] Boost.Function [ ] Boost.Logic [ ] Boost.PropertyMap [ ] Boost.Signals (which is deprecated) [ ] Boost.Tokenizer [x] Boost.MPL [x] Boost.ConceptCheck Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.

Louis Dionne wrote:

...

What's actionable is that if the Boost library requirements contain this, you'll have to go implement it in your own library.

Contain what?

Contain the requirement that a XYZConfig.cmake module be installed along with every Boost.XYZ library. The name of the file and the exact wording are subject to bikeshedding.

What do I need to implement?

See below.

How?

By writing it manually or using a script to generate it. Exactly how to do this should be decided upon by CMake experts as mentioned elsewhere, not by myself. I expect it might be possible to automate this for projects based on Boost.Build, but I don't know Boost.Build well enough to be sure.

I already asked Niall this, I'm asking you. Pick one representative header-only library and one representative non-header-only library as examples and show us what needs to be done. Please.

Sorry for making you wait, the pre-Toronto mailing deadline was this morning and you can guess what I did all day :-). I'm going to show you something, but PLEASE keep in mind this is probably not perfect and CMake experts can probably poke holes in it. I don't claim to have the full solution right away, but the following should give an idea of what needs to be done. So, normally, for a project based on CMake, these XYZConfig.cmake files can be generated automatically by using `install(EXPORT ...)`. The resulting file looks like this (for Hana): https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-what-g... Basically, we'd want to replicate the functionality provided by this module without necessarily all the boilerplate (since that's generated automatically). Here's a minimal file for Hana (a header only library): https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima... And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this): https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima... Then, each Boost library would simply provide a file like this and install it to the appropriate location when the library is installed. Again, please keep in mind this is only the gist of what would need to be done, not an actual template. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Proposal-for-moving-Boost-to-CMake-tp4695... Sent from the Boost - Dev mailing list archive at Nabble.com.

On Jun 19, 2017, at 9:24 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

Louis Dionne wrote:

...

So, normally, for a project based on CMake, these XYZConfig.cmake files can be generated automatically by using `install(EXPORT ...)`. The resulting file looks like this (for Hana):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-what-g...

Basically, we'd want to replicate the functionality provided by this module without necessarily all the boilerplate (since that's generated automatically). Here's a minimal file for Hana (a header only library):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima...

And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima...

Thanks, this gives me an idea what you were proposing. One thing I notice is that you don't enumerate any dependencies. This would work fine in the case where all our header-only libraries are installed into the same include/ as one -I would be as good as any other, I suppose.

He didn’t enumerate the dependencies because in this example there wasn’t any dependencies. If there are dependencies, it would look something like this: include(CMakeFindDependencyMacro) # Bring in the boost::fusion imported target find_dependency(boost_fusion) # Bring in the boost::config imported target find_dependency(boost_config) # Snip the computing imported prefix ... set_target_properties(boost::hana PROPERTIES INTERFACE_COMPILE_FEATURES "cxx_std_14" INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" INTERFACE_LINK_LIBRARIES "boost::fusion;boost::config" IMPORTED_LINK_INTERFACE_LANGUAGES "CXX" IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/libhana.a" # Whatever else you need )

...

Then, each Boost library would simply provide a file like this and install it to the appropriate location when the library is installed.

So, if I understand correctly, you're saying that after `b2 install` in addition to the headers in $prefix/include and the built libraries in $prefix/lib, we should also copy these boost_*-config.cmake files (along with the corresponding -version files maybe?) into $prefix/lib/cmake?

Actually the files will go into $prefix/lib/cmake/boost_pumpkin

Which would then presumably enable find_package(boost_pumpkin)?

Yes.

On Jun 20, 2017, at 3:32 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

On 20 June 2017 at 07:06, P F via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

He didn’t enumerate the dependencies because in this example there wasn’t any dependencies. If there are dependencies, it would look something like this:

include(CMakeFindDependencyMacro) # Bring in the boost::fusion imported target find_dependency(boost_fusion) # Bring in the boost::config imported target find_dependency(boost_config)

# Snip the computing imported prefix ...

set_target_properties(boost::hana PROPERTIES INTERFACE_COMPILE_FEATURES "cxx_std_14" INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" INTERFACE_LINK_LIBRARIES "boost::fusion;boost::config" IMPORTED_LINK_INTERFACE_LANGUAGES "CXX" IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/libhana.a" # Whatever else you need )

Alright I see better how this works, but I don't think CMake generates this automatically, does it? Can this deal with cyclic dependencies?

That is a good question. Cmake can handle cyclic dependencies, but we might need some extra cmake code to avoid recursive calls to `find_dependency`.

On Jun 20, 2017, at 3:25 AM, Mathias Gaunard via Boost <boost@lists.boost.org> wrote:

On 20 June 2017 at 02:28, Louis Dionne via Boost <boost@lists.boost.org> wrote:

...

So, normally, for a project based on CMake, these XYZConfig.cmake files can be generated automatically by using `install(EXPORT ...)`. The resulting file looks like this (for Hana):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897 ca#file-what-gets-generated-for-hana-cmake

Basically, we'd want to replicate the functionality provided by this module without necessarily all the boilerplate (since that's generated automatically). Here's a minimal file for Hana (a header only library):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897 ca#file-minimal-handwritten-config-header-only-cmake

And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897 ca#file-minimal-handwritten-config-static-cmake

Then, each Boost library would simply provide a file like this and install it to the appropriate location when the library is installed. Again, please keep in mind this is only the gist of what would need to be done, not an actual template.

I'm not sure this is the right approach, what happens when you have a transitive dependency? I'd rather just like the direct dependencies, but this format looks like it would need to contain the transitive dependencies too.

The transitive dependency is taken care of by calling `find_package` for each dependency. That is, if Boost.Hana depends on Boost.Foo, then Boost.Hana only states that it depends on some target boost::foo, but this will be defined by `find_package(foo)`, which if that depends another library it will go through the same process.

On Thu, Jun 22, 2017 at 3:48 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

Louis Dionne wrote:

And here's a minimal XYZConfig.cmake file for a library with compiled

...

sources (I added source files to Hana and turned it into a static library to check this):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d8 97ca#file-minimal-handwritten-config-static-cmake

To get back to this... it ain't so easy. On Linux, where the default is --layout=system, you indeed can only have libhana.a and libhana.so (a link to libhana.so.1.65.0 or something like that).

But on Windows, `b2 --build-type=complete --with-system toolset=msvc-14.1` gives you this:

boost_system-vc141-mt-1_65.dll boost_system-vc141-mt-1_65.lib boost_system-vc141-mt-gd-1_65.dll boost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-1_65.lib libboost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-s-1_65.lib libboost_system-vc141-mt-sgd-1_65.lib libboost_system-vc141-s-1_65.lib libboost_system-vc141-sgd-1_65.lib

and of course compiling with a different toolset would give you the appropriate, different, names. You can have all of these installed simultaneously.

So boost_system-config.cmake needs to be slightly more elaborate.

One way to go here is to have one Config.cmake for each build type. For example structured like this: lib/cmake/boost-vc141-mt-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-static/boost_system-config.cmake The user could then point BOOST_ROOT to the directory of her choice (or other choices as described here: https://cmake.org/cmake/help/v3.9/command/find_package.html#command:find_pac... ). An alternative to this would be to play a guessing game based on CMAKE_CXX_COMPILER_ID and friends. And, in addition, let the user choose which variant (gd, s or sgd) to choose (with a sensible default) under: lib/cmake/boost/boost_system-config.cmake with a content similar to this (pseudo code from the top of my head): if(USER_VARIANT) include(../boost-${USER_VARIANT}/boost_system-config.cmake) elseif(MSCV_VERSION EQUALS 1900) include(../boost-vc141-${VARIANT}/boost_system-config.cmake) elseif(... more compiler checks ....) .... else() message(FATAL_ERROR "could not guess version and no user specified one set") endif() This should give maximal flexibility for power users with an easy and convenient entry point that most of the time works.

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

On 22/06/2017 13:11, Peter Dimov via Boost wrote:

Thomas Heller wrote:

...

One way to go here is to have one Config.cmake for each build type. For example structured like this:

lib/cmake/boost-vc141-mt-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-static/boost_system-config.cmake

Yikes, I thought this was supposed to make things simpler/better? Whatever we end up with, it needs to be something that cmake-o-phobes like myself that have never looked inside a cmake file can still maintain relatively easily. With regard to Windows / msvc usage, I see two main usage requirements: 1) The ability to build all the variants we do at present, so that folks can just build Boost as they do now, and then point their IDE at the directory containing the .lib files. 2) The ability to take the Visual Studio files generated by CMake, and add the library targets directly to their own project "solutions" so that their own projects can reference them. #1 we do already, #2 would be a very useful feature for Visual Studio users - way more useful than being able to reference Boost from other CMake files for folks like me. Probably the easiest way to support those two, would be to have a *single* CMake target for each library (which generates a single VS project, OK may have to be 2 - one static and one dll), and then a separate install step that renames the lib/dll depending on how it was built. I also noticed someone wanting to link debug application with release Boost library: but you can't in general do that with the Visual Studio builds - the whole reason we support all these variants is that they are built against different runtime libraries and are therefore binary incompatible. What you can do, is build a debug library (as in links to the debug runtime) but turn on optimizations. BTW These variants along with auto-linking were things I introduced with Regex long before it was in Boost - before that I used to get a couple of support requests a week from folks trying to link incompatible binaries, building all the variants along with the auto-linking killed that problem dead. And boost usage has exploded hugely since those early days. Just trying to emphasise how important the feature is ;) And now I'll go back to lurking, John. --- This email has been checked for viruses by AVG. http://www.avg.com

On Jun 21, 2017, at 8:48 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

Louis Dionne wrote:

...

And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima...

To get back to this... it ain't so easy. On Linux, where the default is --layout=system, you indeed can only have libhana.a and libhana.so (a link to libhana.so.1.65.0 or something like that).

But on Windows, `b2 --build-type=complete --with-system toolset=msvc-14.1` gives you this:

boost_system-vc141-mt-1_65.dll boost_system-vc141-mt-1_65.lib boost_system-vc141-mt-gd-1_65.dll boost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-1_65.lib libboost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-s-1_65.lib libboost_system-vc141-mt-sgd-1_65.lib libboost_system-vc141-s-1_65.lib libboost_system-vc141-sgd-1_65.lib

and of course compiling with a different toolset would give you the appropriate, different, names. You can have all of these installed simultaneously.

So boost_system-config.cmake needs to be slightly more elaborate.

Yes. For debug and release variants, I believe you can use the `$<CONFIG>` generator expression: set_target_properties(boost::system PROPERTIES IMPORTED_IMPLIB "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-gd-1_65.lib,boost_system-vc141-mt-1_65.lib>" IMPORTED_LOCATION "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-gd-1_65.dll,boost_system-vc141-mt-1_65.dll>" ) Which will pick debug or release based on that. However, to choose between the other variants, we can probably use the `COMPONENTS` arguments in `find_package`. So the user can say `find_package(boost_system COMPONENTS static mt)`, or something like that. We also, probably want to make the components requests transitive as well: find_dependency(boost_system COMPONENTS ${${CMAKE_FIND_PACKAGE_NAM}_FIND_COMPONENTS})

On Jun 22, 2017, at 4:36 AM, Thomas Heller <thom.heller@gmail.com> wrote:

On Thu, Jun 22, 2017 at 11:30 AM, P F via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

...

On Jun 21, 2017, at 8:48 PM, Peter Dimov via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:

Louis Dionne wrote:

...

And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this):

https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minima... <https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#file-minimal-handwritten-config-static-cmake>

To get back to this... it ain't so easy. On Linux, where the default is --layout=system, you indeed can only have libhana.a and libhana.so (a link to libhana.so.1.65.0 or something like that).

But on Windows, `b2 --build-type=complete --with-system toolset=msvc-14.1` gives you this:

boost_system-vc141-mt-1_65.dll boost_system-vc141-mt-1_65.lib boost_system-vc141-mt-gd-1_65.dll boost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-1_65.lib libboost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-s-1_65.lib libboost_system-vc141-mt-sgd-1_65.lib libboost_system-vc141-s-1_65.lib libboost_system-vc141-sgd-1_65.lib

and of course compiling with a different toolset would give you the appropriate, different, names. You can have all of these installed simultaneously.

So boost_system-config.cmake needs to be slightly more elaborate.

Yes. For debug and release variants, I believe you can use the `$<CONFIG>` generator expression:

set_target_properties(boost::system PROPERTIES IMPORTED_IMPLIB "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-gd-1_65.lib,boost_system-vc141-mt-1_65.lib>" IMPORTED_LOCATION "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-gd-1_65.dll,boost_system-vc141-mt-1_65.dll>" )

There are use cases when I want to get the release build of boost even though my own build type is set to Debug. The build type in addition is also completely customizable (see for example the MSVC CMake integration). What should happen when my build type is RelWithDebInfo or MinSizeRel? There should always be a way for users to bail out of the guessing game.

This isn’t based on the `CMAKE_BUILD_TYPE`(which is a configuration variable). Its based on the configuration set at build time: cmake --build . --config debug Which `debug` and `release`, I believe, are the only valid options. Of course, the choice between the debug/release is only when user has chosen to build both variants in the same build tree/installation. If you want to use release versions of boost during a debug build, then its best to build only the release version of boost, so the config.cmake would just be this: set_target_properties(boost::system PROPERTIES IMPORTED_IMPLIB "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-1_65.lib>" IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-1_65.dll>" ) Then its just a matter of adjusting your `CMAKE_PREFIX_PATH` to point to different variants.

On Thu, 2017-06-22 at 12:24 +0200, Thomas Heller wrote:

On Thu, Jun 22, 2017 at 11:58 AM, P F <pfultz2@yahoo.com> wrote:

...

...

On Jun 22, 2017, at 4:36 AM, Thomas Heller <thom.heller@gmail.com> wrote:

On Thu, Jun 22, 2017 at 11:30 AM, P F via Boost <boost@lists.boost.org>  wrote:

...

...

On Jun 21, 2017, at 8:48 PM, Peter Dimov via Boost <boost@lists.boos t.org> wrote:

Louis Dionne wrote:

...

And here's a minimal XYZConfig.cmake file for a library with compiled sources (I added source files to Hana and turned it into a static library to check this):

 https://gist.github.com/ldionne/df7b6888752097e25bfc2333f6d897ca#fi le-minimal-handwritten-config-static-cmake

To get back to this... it ain't so easy. On Linux, where the default is --layout=system, you indeed can only have libhana.a and libhana.so (a link to libhana.so.1.65.0 or something like that).

But on Windows, `b2 --build-type=complete --with-system toolset=msvc-14.1` gives you this:

boost_system-vc141-mt-1_65.dll boost_system-vc141-mt-1_65.lib boost_system-vc141-mt-gd-1_65.dll boost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-1_65.lib libboost_system-vc141-mt-gd-1_65.lib libboost_system-vc141-mt-s-1_65.lib libboost_system-vc141-mt-sgd-1_65.lib libboost_system-vc141-s-1_65.lib libboost_system-vc141-sgd-1_65.lib

and of course compiling with a different toolset would give you the appropriate, different, names. You can have all of these installed simultaneously.

So boost_system-config.cmake needs to be slightly more elaborate.

Yes. For debug and release variants, I believe you can use the `$<CONFIG>` generator expression:

set_target_properties(boost::system PROPERTIES   IMPORTED_IMPLIB "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt- gd-1_65.lib,boost_system-vc141-mt-1_65.lib>"   IMPORTED_LOCATION "$<IF:$<CONFIG:release>,${_IMPORT_PREFIX}/lib/boost_system-vc141-mt- gd-1_65.dll,boost_system-vc141-mt-1_65.dll>" )

There are use cases when I want to get the release build of boost even though my own build type is set to Debug. The build type in addition is also completely customizable (see for example the MSVC CMake integration). What should happen when my build type is RelWithDebInfo or MinSizeRel? There should always be a way for users to bail out of the guessing game. This isn’t based on the `CMAKE_BUILD_TYPE`(which is a configuration variable). Its based on the configuration set at build time:

cmake --build . --config debug

Which `debug` and `release`, I believe, are the only valid options. 

They are not. As said, they can be arbitrary.

Thats true. We have to use the `DEBUG_CONFIGURATIONS` propery to know which configurations are for debug.

`cmake --build . --config debug` is just another way of kicking of the build for a given build type. That is, setting `CMAKE_BUILD_TYPE` (and calling make directly after) and the aforementioned command are equivalent.

This is not true at all. It never changes the `CMAKE_BUILD_TYPE`. The `CMAKE_BUILD_TYPE` is for single configuration buildsystems(like make), but is ignored for multi-configuration build systems(like MSVC and XCode). At the same time, `--config` is ignored on single configuration buildsystems. 

 

...

Of course, the choice between the debug/release is only when user has chosen to build both variants in the same build tree/installation. If you want to use release versions of boost during a debug build, then its best to build only the release version of boost, so the config.cmake would just be this:

set_target_properties(boost::system PROPERTIES   IMPORTED_IMPLIB "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt-1_65.lib>"   IMPORTED_LOCATION "${_IMPORT_PREFIX}/lib/boost_system-vc141-mt- 1_65.dll>" )

Then its just a matter of adjusting your `CMAKE_PREFIX_PATH` to point to different variants.

The problem here is that, at the time of a b2 invocation, you don't know if the user doesn't build more variants. Meaning, even though, the libraries are perfectly fine with living next to each other, the CMake Configs would not. This would IMHO create a disparity between the features of Boost.Build and what's being offered by the CMake integration.

Yes, and if boost was to move to cmake, the result might be different as well. It might be better to only generate the configs when building for a single variant, although that would make `b2 variant=debug,release` different from `b2 variant=debug && b2 variant=release`.

On 6/18/17 3:06 PM, P F via Boost wrote:

And the next question is how do we maintain these? That is how do we tests these to make sure that they are correct for the boost release?

LOL - we're asking you! Robert Ramey

Am 18.06.2017 um 21:05 schrieb Louis Dionne via Boost:

Boost.Build only is a major pain for our users since they (1) most likely don't use it in house, (2) don't know it, (3) don't want to learn it, and (4) have to deal with it whether they like it or not. If you go into the wild, you'll find - people that don't use Boost because it's too hard to build or integrate into their build system - people that only use the header-only libraries because they don't have to build them and/or because the integration is as simple as changing a header path - people that build properly but are tired of maintaining their bridge between Boost.Build and their own system

And then there are people (e.g. the developers in our organization) who - have no clue about building any boost library - don't care if a given boost library is header-only or not - deal with the build system no more than pressing one button in the ide - handle dependencies to boost by nothing more but stating "1.64.0" at one single place in the whole software project. Finding the Boost headers and auto-linking the pre-built libs matching their compiler version, mode and bitness is *not* their business - that's done by the build system. That's all these people need to know in their role as "users". It's my duty to make all of this happen without any sort of pain for them. We are talking about Windows, MSVC and MSBuild here and this is the experience our developers are accustomed to for years now. I am totally aware that the story might be different for Linux, MacOS, et. al. I have no problem in servicing my colleagues this way as long as a Boost version is tested and versioned as a integrated composition of libraries which builds with Boost.Build as only prerequisite. Just my 2ct from my pov. Ciao Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

On Mon, Jun 19, 2017 at 2:20 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

Le 17/06/2017 à 01:44, David Sankel via Boost a écrit :

...

Howdy all,

This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback.

<snip>

I see this progressing with several milestones.

1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed.

What will be wrong supporting two build systems, at least for a while?

Nothing at all. My expectation was that the time between steps 3 and 4 would be years.