I see that individual repositories like boostorg/filesystem on Github have a CMakeLists.txt. But the boostorg/boost super repo doesn't have a root CMakeLists.txt. Either this doesn't follow standard CMake structure or there's no way to build with CMake globally instead of bjam. How can I build the boost libraries with CMake?
On Tue, 8 Oct 2019 at 16:30, Robert Dailey via Boost-users <boost-users@lists.boost.org> wrote:
I see that individual repositories like boostorg/filesystem on Github have a CMakeLists.txt. But the boostorg/boost super repo doesn't have a root CMakeLists.txt. Either this doesn't follow standard CMake structure or there's no way to build with CMake globally instead of bjam.
It is the latter. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Tue, Oct 8, 2019 at 10:06 AM Mateusz Loskot via Boost-users <boost-users@lists.boost.org> wrote:
On Tue, 8 Oct 2019 at 16:30, Robert Dailey via Boost-users <boost-users@lists.boost.org> wrote:
I see that individual repositories like boostorg/filesystem on Github have a CMakeLists.txt. But the boostorg/boost super repo doesn't have a root CMakeLists.txt. Either this doesn't follow standard CMake structure or there's no way to build with CMake globally instead of bjam.
It is the latter.
Why, then, do the individual libs have CMake support? What's the point if you can't build the complete boost library with it?
On Tue, 8 Oct 2019 at 17:52, Robert Dailey <rcdailey.lists@gmail.com> wrote:
On Tue, Oct 8, 2019 at 10:06 AM Mateusz Loskot via Boost-users <boost-users@lists.boost.org> wrote:
On Tue, 8 Oct 2019 at 16:30, Robert Dailey via Boost-users <boost-users@lists.boost.org> wrote:
I see that individual repositories like boostorg/filesystem on Github have a CMakeLists.txt. But the boostorg/boost super repo doesn't have a root CMakeLists.txt. Either this doesn't follow standard CMake structure or there's no way to build with CMake globally instead of bjam.
It is the latter.
Why, then, do the individual libs have CMake support? What's the point if you can't build the complete boost library with it?
Boost is a collection of C++ libraries where each library has a fair bit of freedom of how it is being developed; each has their developers and maintainers who are free to add any build configuration they like as local/internal per the library they maintain. For example, Boost.Beast and Boost.GIL, both header-only libraries, allow their contributors to build tests and examples using CMake. So, CMake-lovers should follow instructions specific to those libraries: https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md https://github.com/boostorg/beast#building-tests-and-examples If you search carefully, you may even find .sln and .vcxproj files dangling in folders of some libraries. It does not mean you can build whole Boost by opening the .sln file in VS and hitting Ctrl+Shift+B. If there is a maintainer of a Boost library who likes Bazel or Premake, you may see configuration files for those as well. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Tue, Oct 8, 2019 at 11:29 AM Mateusz Loskot via Boost-users <boost-users@lists.boost.org> wrote:
Boost is a collection of C++ libraries where each library has a fair bit of freedom of how it is being developed; each has their developers and maintainers who are free to add any build configuration they like as local/internal per the library they maintain.
For example, Boost.Beast and Boost.GIL, both header-only libraries, allow their contributors to build tests and examples using CMake. So, CMake-lovers should follow instructions specific to those libraries: https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md https://github.com/boostorg/beast#building-tests-and-examples
If you search carefully, you may even find .sln and .vcxproj files dangling in folders of some libraries. It does not mean you can build whole Boost by opening the .sln file in VS and hitting Ctrl+Shift+B.
If there is a maintainer of a Boost library who likes Bazel or Premake, you may see configuration files for those as well.
Thanks for explaining. I figured it would be a little more complicated than that because: 1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself). 2. Dependency management. Boost.Filesystem depends on Boost.System. But what if Boost.System maintainers didn't want to use CMake? I don't know how you guys are solving these problems. To me it is much simpler to use CMake for everything. Not sure why the super repo hasn't adopted it yet. I recall a project to do CMake for boost that started years ago.
On Tue, 8 Oct 2019 at 18:34, Robert Dailey <rcdailey.lists@gmail.com> wrote:
On Tue, Oct 8, 2019 at 11:29 AM Mateusz Loskot via Boost-users <boost-users@lists.boost.org> wrote:
Boost is a collection of C++ libraries where each library has a fair bit of freedom of how it is being developed; each has their developers and maintainers who are free to add any build configuration they like as local/internal per the library they maintain.
For example, Boost.Beast and Boost.GIL, both header-only libraries, allow their contributors to build tests and examples using CMake. So, CMake-lovers should follow instructions specific to those libraries: https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md https://github.com/boostorg/beast#building-tests-and-examples
If you search carefully, you may even find .sln and .vcxproj files dangling in folders of some libraries. It does not mean you can build whole Boost by opening the .sln file in VS and hitting Ctrl+Shift+B.
If there is a maintainer of a Boost library who likes Bazel or Premake, you may see configuration files for those as well.
Thanks for explaining. I figured it would be a little more complicated than that because:
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
2. Dependency management. Boost.Filesystem depends on Boost.System. But what if Boost.System maintainers didn't want to use CMake?
No need to. If maintainer of Boost.Filesystem wants to offer CMake config for contributors to his library (I emphasise the word "contributors"), then it is documented that in order to run CMake, build whole Boost or Filesystem's deps b2 --with-system ... That precisely is what GIL does https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md#using-cmake
To me it is much simpler to use CMake for everything. Not sure why the super repo hasn't adopted it yet.
That is your opinion. You are free to pitch for CMake but this is not the right place. This one is https://lists.boost.org/boost/
I recall a project to do CMake for boost that started years ago.
There were at least three such initiatives, if I remember correctly. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice? I also second the idea of having a unique top level CMake (plus individual CMake for each library) build system to build all libraries. Especially since CMake is much superior to bjam regarding portability and options. For now each time I need to configure Boost for a custom build I need to spend a lot of time in the Boost Build documentation which isn't easy IMHO. Regards, -- David
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> On Behalf Of David Demelier via Boost-users Sent: 10 October 2019 13:46 To: boost-users@lists.boost.org Cc: David Demelier <markand@malikania.fr> Subject: Re: [Boost-users] Building with CMake?
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
I also second the idea of having a unique top level CMake (plus individual CMake for each library) build system to build all libraries. Especially since CMake is much superior to bjam regarding portability and options. For now each time I need to configure Boost for a custom build I need to spend a lot of time in the Boost Build documentation which isn't easy IMHO.
You are right - bjam remains very difficult (but many users believe that it is also more powerful than CMake). But it is also not easy as you suggest to replicate the bjam settings using CMake -an expert has been working on Boost.Multiprecision for some months now, and that is much easier than Boost.Math for example. When all the individual libraries have their CMake working, then it is perhaps the time to tackle the top-level? If you want to get Boost entirely CMake, you need to 'put your money where your mouth is', and contribute. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On Thu, 10 Oct 2019 at 14:46, David Demelier via Boost-users <boost-users@lists.boost.org> wrote:
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
None taken.
I also second the idea of having a unique top level CMake (plus individual CMake for each library) build system to build all libraries. Especially since CMake is much superior to bjam regarding portability and options.
We all have right to our own opinions. I just addressed some very concrete questions related to existence of CMakeLists.txt files for some of Boost libraries. Please, excuse me the lack of answers to your questions, but I am not going to allow myself to get dragged into yet another never-ending nowhere-leading inconclusive thread of Boost.Build vs CMake wrestling . There have been many, for some too many, of those over the last few years. Still nobody has come up with a solid working solution acceptable by all parties involved in using and developing Boost. Indicative, isn't it (rhetoric). Disclaimer: I'm a CMake daily user and sporadic contributor to CMake myself, with a decade long experience configuring numerous non-trivial open source projects for CMake 2.8, then modernizing to CMake 3, 3.5 and later, who have learned that "CMake is much superior to Boost.Build" generalizations deserve to be flushed with power of toilet water. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Hello to all, as someone who implemented boost as a dependency into a CMake Project I would suggest a simple solution based on this. Just one CMake File that builds with bjam as a subproject and manages to redirect all compiler related settings. I can provide my sample implementation if there is interest in it. Regards, Simon Am 10.10.19 um 16:32 schrieb Mateusz Loskot via Boost-users:
On Thu, 10 Oct 2019 at 14:46, David Demelier via Boost-users <boost-users@lists.boost.org> wrote:
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
None taken.
I also second the idea of having a unique top level CMake (plus individual CMake for each library) build system to build all libraries. Especially since CMake is much superior to bjam regarding portability and options.
We all have right to our own opinions.
I just addressed some very concrete questions related to existence of CMakeLists.txt files for some of Boost libraries.
Please, excuse me the lack of answers to your questions, but I am not going to allow myself to get dragged into yet another never-ending nowhere-leading inconclusive thread of Boost.Build vs CMake wrestling . There have been many, for some too many, of those over the last few years.
Still nobody has come up with a solid working solution acceptable by all parties involved in using and developing Boost. Indicative, isn't it (rhetoric).
Disclaimer: I'm a CMake daily user and sporadic contributor to CMake myself, with a decade long experience configuring numerous non-trivial open source projects for CMake 2.8, then modernizing to CMake 3, 3.5 and later, who have learned that "CMake is much superior to Boost.Build" generalizations deserve to be flushed with power of toilet water.
Best regards,
That's good, but not what the OP (or Original Complainant 😉 ) had in mind? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> On Behalf Of Simon Michalke via Boost-users Sent: 11 October 2019 10:24 To: boost-users@lists.boost.org Cc: Simon Michalke <simon.michalke@fau.de> Subject: Re: [Boost-users] Building with CMake?
Hello to all,
as someone who implemented boost as a dependency into a CMake Project I would suggest a simple solution based on this. Just one CMake File that builds with bjam as a subproject and manages to redirect all compiler related settings. I can provide my sample implementation if there is interest in it.
Regards, Simon
Am 10.10.19 um 16:32 schrieb Mateusz Loskot via Boost-users:
On Thu, 10 Oct 2019 at 14:46, David Demelier via Boost-users <boost-users@lists.boost.org> wrote:
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
None taken.
I also second the idea of having a unique top level CMake (plus individual CMake for each library) build system to build all libraries. Especially since CMake is much superior to bjam regarding portability and options.
We all have right to our own opinions.
I just addressed some very concrete questions related to existence of CMakeLists.txt files for some of Boost libraries.
Please, excuse me the lack of answers to your questions, but I am not going to allow myself to get dragged into yet another never-ending nowhere-leading inconclusive thread of Boost.Build vs CMake wrestling . There have been many, for some too many, of those over the last few years.
Still nobody has come up with a solid working solution acceptable by all parties involved in using and developing Boost. Indicative, isn't it (rhetoric).
Disclaimer: I'm a CMake daily user and sporadic contributor to CMake myself, with a decade long experience configuring numerous non-trivial open source projects for CMake 2.8, then modernizing to CMake 3, 3.5 and later, who have learned that "CMake is much superior to Boost.Build" generalizations deserve to be flushed with power of toilet water.
Best regards,
On Fri, Oct 11, 2019 at 4:29 AM Simon Michalke via Boost-users < boost-users@lists.boost.org> wrote:
as someone who implemented boost as a dependency into a CMake Project I would suggest a simple solution based on this. Just one CMake File that builds with bjam as a subproject and manages to redirect all compiler related settings.
Boost libraries are also available via conan in bintray. -- Chris Cleeland
On Thu, Oct 10, 2019, 15:46 David Demelier via Boost-users < boost-users@lists.boost.org> wrote: Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
For me, Boost Build is more scalable, better designed, encouraging a saner workflow and file organization, more ambitious, and easier to understand than other build systems I have used. I personally think there is much to learn from working with it. I hope one day we can make it work a little faster and allow users to override dependence-or-independence of specific targets on specific features/properties. But still, I love Boost Build.
PLOT TWIST: Boost Build uses CMake internally. DUN DUN dunnnnn... (Sorry about that. I have no idea if that’s true. I know this probably will get me kicked out of this list, but you know, right time, right place :)
El 24 nov. 2019, a la(s) 10:32, Adder via Boost-users <boost-users@lists.boost.org> escribió:
On Thu, Oct 10, 2019, 15:46 David Demelier via Boost-users <boost-users@lists.boost.org> wrote:
Le 08/10/2019 à 18:52, Mateusz Loskot via Boost-users a écrit :
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
It is not as difficult or time consuming as one may think.
No offense but who on earth except Boost really use bjam by choice?
For me, Boost Build is more scalable, better designed, encouraging a saner workflow and file organization, more ambitious, and easier to understand than other build systems I have used.
I personally think there is much to learn from working with it.
I hope one day we can make it work a little faster and allow users to override dependence-or-independence of specific targets on specific features/properties.
But still, I love Boost Build. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Mon, Nov 25, 2019 at 10:39 AM Heriberto Delgado via Boost-users < boost-users@lists.boost.org> wrote:
PLOT TWIST: Boost Build uses CMake internally.
DUN DUN dunnnnn...
(Sorry about that. I have no idea if that’s true.
I know this probably will get me kicked out of this list, but you know, right time, right place :)
Hahaha... It doesn't. But still funny. REAL PLOT TWIST: Cmake became "Modern Cmake" by borrowing design ideas from Boost Build! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> On Behalf Of Robert Dailey via Boost-users Sent: 8 October 2019 17:34 To: Boost <boost-users@lists.boost.org> Cc: Robert Dailey <rcdailey.lists@gmail.com> Subject: Re: [Boost-users] Building with CMake?
On Tue, Oct 8, 2019 at 11:29 AM Mateusz Loskot via Boost-users <boost- users@lists.boost.org> wrote:
Boost is a collection of C++ libraries where each library has a fair bit of freedom of how it is being developed; each has their developers and maintainers who are free to add any build configuration they like as local/internal per the library they maintain.
For example, Boost.Beast and Boost.GIL, both header-only libraries, allow their contributors to build tests and examples using CMake. So, CMake-lovers should follow instructions specific to those libraries: https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md https://github.com/boostorg/beast#building-tests-and-examples
If you search carefully, you may even find .sln and .vcxproj files dangling in folders of some libraries. It does not mean you can build whole Boost by opening the .sln file in VS and hitting Ctrl+Shift+B.
If there is a maintainer of a Boost library who likes Bazel or Premake, you may see configuration files for those as well.
Thanks for explaining. I figured it would be a little more complicated than that because:
1. This essentially means library maintainers are choosing to maintain at least 2 build systems (bjam for overall boost build, + whatever preferential build system they use for the library itself).
2. Dependency management. Boost.Filesystem depends on Boost.System. But what if Boost.System maintainers didn't want to use CMake?
I don't know how you guys are solving these problems. To me it is much simpler to use CMake for everything. Not sure why the super repo hasn't adopted it yet. I recall a project to do CMake for boost that started years ago.
Indeed - and it is still a work in progress, but it is *much* more difficult that it might appear, and requires time and special skills in both CMake, bjam and each and every individual Boost libraries. If you have something to contribute, you are most welcome to help 😉 Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
participants (1)
-
Adder -
Chris Cleeland -
David Demelier -
Heriberto Delgado -
Mateusz Loskot -
pbristow＠hetp.u-net.com -
Rene Rivera -
Robert Dailey -
Simon Michalke