Re: A proposal for a modern build-system

From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2025-05-06 21:03:42

On Tue, May 6, 2025 at 10:39 PM Дмитрий Архипов via Boost
<boost_at_[hidden]> wrote:
>
> вт, 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.
>

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