Re: A proposal for a modern build-system

From: Дмитрий Архипов (grisumbras_at_[hidden])
Date: 2025-05-06 19:39:30

вт, 6 мая 2025 г. в 17:55, Artyom Beilis via Boost <boost_at_[hidden]>:
> 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.

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