Re: [boost] On Boost and modules

On 09.04.24 16:33, Дмитрий Архипов via Boost wrote:

вт, 9 апр. 2024 г. в 16:43, Rainer Deyke via Boost : first. Build systems aren't going anywhere, as well as compiled libraries.

...

I'm fine with one build system. The one I use to compile my own code. I'm not fine with the dozen or so build systems I currently have to use to build my dependencies.

This is already solved by package managers. They deal with dependencies' build systems for you and create "exports" for your build system.

I think you mean it /could/ be solved by a /hypothetical/ package manager. Because it's not solved by any actual package manager I know. I tried Conan. I ran into the following problems: - Even getting it to work with a trivial test program is a pain in the ass. - It's based on binary packages, which means very limited configurability for packages to avoid a combinatorial explosion of package files. - It does not come with all of libraries I use, or even a significant subset thereof. - The libraries it does host are often broken. - It wants to fetch packages from the internet, which means that build scripts aren't future proof, because stuff disappears from the internet all the time. To avoid this I would have to host my own repository, which is again a huge pain in the ass. - It tries to be "build system agnostic", which means I need still be fluent in a dozen or so build systems to fix things inevitably go wrong. I did not try any others, but that's because I was turned away from them before I even downloading them. I'm currently taking a second looks at build2. I haven't got very far, but I'm already starting to hate it.

...

You don't recompile the dependencies "all the time". You compile once per configuration and recompile when the dependency changes, same as any other source file. Your build system takes care of this.

But you do. I would think, most projects are built in CI these days. CI can get you pre-built binaries for your dependencies. But BMIs are not redistributable, as we've been told it is not even a goal. The best you can do in order to not rebuild every module for every job is CI runner cache.

That sounds like a problem with your build system. I do "from scratch" builds every so often. They take about a week to run. Of course, "from scratch" for me includes compiling the tools I use to build the tools, including the compiler.

...

This means that there is just one way of configuring a library, by defining configuration macros. No messing around with CMake variables or command-line arguments for configure scripts or whatever Meson or SCons use.

Nothing stops you from using macros even now. E.g. with CMake: CXXFLAGS=-DMYLIB_MACRO=1 cmake -S. -Bbuild

With b2: b2 define=MYLIB_MACRO=1

And a third syntax for SCons, and a fourth for autotools, and a fifth for Meson, and so on. The whole point is to avoid having to learn a dozen different build tools, each with their own command line syntax.

There must be a reason projects prefer to use configuration options and not macros directly.

The main reason is that people are stuck on the library binaries model (whether static or dynamic) - a model that has been obsolete since C++ first gained templates. -- Rainer Deyke (rainerd@eldwood.com)