On Tue, May 6, 2025 at 10:39 PM Дмитрий Архипов via Boost <boost@lists.boost.org> wrote:
вт, 6 мая 2025 г. в 17:55, Artyom Beilis via Boost <boost@lists.boost.org>:
See, I discussed it a lot back in 2011 on this list.
As bottom line when I worked on Boost.Locale having large experience with both, autotools cmake and even basic makefiles I totally failed to perform all tasks I needed I don't recall exactly but basic stuff like finding 3rd party libraries or conditional builds was total nightmare and very hard to maintain.
Compare for example cmake: https://github.com/boostorg/locale/blob/develop/CMakeLists.txt and jamfile https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2 that is twice as large and some tests that are built in in cmake (like test header/library) are generated in separate build
I looked at those two files. As far as I can see, the vast majority of that jamfile is configuring dependencies, particularly Iconv and ICU. The only reason there's nothing similar in the CMakeLists.txt is because there are Find modules for those libraries provided with CMake. Ironically enough, they were not provided with CMake in 2011 (FindICU is provided since version 3.7 which was released in 2016, FindIconv since version 3.11 released in 2018). Moreover, things like private/public properties were only added to CMake in 2013. Again, ironically as an effort to copy b2 usage requirements.
Actually in cppcms/booster.locale original cmake (where boost.locale came from) I used one liners to find headers and libraries only difference was for debug build to find iculibrary with "d" suffix, I didn't use predefined FindICU Now finding 3rd part library is the central part of the configuration/build system for real world projects. Looking as an example at my big FOSS C++ project dependencies CppCMS: icu, zlib, openssl/gnu-tls, iconv, pcre, python CppDB: mysql, odbc, postgresql, sqlite Dlprimitives: python, sqlite, OpenCL, protobuf, openblas/cblas, hdf5, boost-python, boost-numpy OpenLiveStacker: libtiff, cppcms, libcurl, indilib, indigo, libraw, libgphoto, opencv, cfitsio, libusb, asisdk, touptek sdk, zlib, android camera2 And finding each of them in CMake is virtually two lines (header, library) and I rarely use FindXXX with exception of some complex stuff (ironically boost python) So Boost is quite a unicorn when the vast majority of the libraries are header only or come with 0 dependencies and using icu in Regex in Locale was a major event. So from the point of view of somebody who comes from outside it is bare practicality and simplicity of using/configuring the dependencies.
Bottom line, in my opinion bjam is a very limited build system. Maybe it servers Boost ok, but I would never choose one outside the scope mostly due its design of doing everything in the same flow under all conditions rather than the much simpler and easy to use CMake approach.
I can agree that it could be more easy to think in exactly one configuration. Which makes writing b2 build scripts properly more challenging than CMake build scripts. But ironically again, this part of b2 complexity also gradually enters CMake due to multiconfig generators (just look at generator expressions). Nevertheless, I find it strange that you call b2 very limited compared to CMake, when it's actually more powerful, and it's exactly that power that incurs complexity.
I understand what you are talking about because for windows build there is a huge matrix of Under Windows {Release,Debug}x{DynamicLink,StaticLink}x{DynamicRuntime,StaticRuntime} And under Linux it is typically shared object and static object - BTW something that autotools did very well and drive me crazy at the beginning with CMake - autotools buid automatically shared object and static while in cmake it is more verbose Now typically under windows you have two Debug and Release runtimes because they are ABI incompatible (not going to why they did such a dreadful decision - but it is another topic) So there is a mode in cmake that tries to build them both - and it does not work well that is why I never support VS projects with dual builds in my cmakes and tell windows users grab ninja and do a separate build for each of the debub or release configurations. So yes for building crazy matrices bjam helps a lot I totally agree - but all this till you need to find appropriate dependency for each and every case and turn on/off a feature if you found it or not - and not it becomes a nightmare since you may found ICU for dynamic linking in release but not for static linking or not for debug. So I do understand practicality of Boost Build bjam for Boost itself (as long as you don't need any 3rd party) but I find it rather unpractical for outside of the Boost crib Artyom