Re: On Boost and modules

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-10 11:05:51

On 09.04.24 16:33, Дмитрий Архипов via Boost wrote:
> вт, 9 апр. 2024 г. в 16:43, Rainer Deyke via Boost <boost_at_[hidden]>:
>   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_at_[hidden])