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
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,