Re: On Boost and modules

From: Boris Kolpackov (boris_at_[hidden])
Date: 2024-04-11 09:44:05

[I am keeping the list CC'ed seeing that there is interest in
this subject. But let me know if anyone feels this is veering
too much off-topic.]

Rainer Deyke via Boost <boost_at_[hidden]> writes:

> I haven't delved deep into Build2 yet (as stated above), so I could be
> misinterpreting things.  I also haven't given up on it yet.

Glad to hear.

There are a few mis-conceptions below (which, I accept, are in large part
due to the complexity and "we often do things differently"):

>   - bdep creates a <project_name>/<project_name> hierarchy.  I assume the
> outer <project_name> directory is the package and the inner <project_name>
> is the project within the package.  But wait, there's one more level!  I
> can't put my build directories in the inner /or/ the outer <project_name>,
> so in practice I've got three levels:
> <project_name>/<project_name>/<project_name>.

That's the default structure and there is rationale[1] for it, though as
most things in this area, it's a trade-off and not everyone agrees with
the choices we've made.

The good news is that the layout can be customized to generate pretty
much any layout you want, split (include/src) or combined, with nested
subdirectories or without, etc. We have a section in the documentation
that shows how to create over a dozen layouts, including the one used
in Boost:

https://build2.org/bdep/doc/bdep-new.xhtml#src-layout

>   - I need to specify the name for each build configuration twice, once for
> the @name and once for the directory.

Hm, not sure where you got this impression. The only time you need to
specify both is when creating the configuration. Even in this case the
directory is actually optional and if you don't specify it, you will
get ../<project>-<name> by default.

Here is a typical "create a throw-away project to quickly test
something" workflow:

$ bdep new hello
$ cd hello
$ bdep init -C @gcc cc config.cxx=g++
$ bdep init -C @clang cc config.cxx=clang++
$ bdep update @gcc
$ bdep update @clang
$ ls -1 ../
hello
hello-gcc
hello-clang

>   - It wants me to use git.  I strongly prefer fossil as my version control
> system.

You can use build2 without git. You will loose quite a bit of "nice to have"
functionality, mostly in bdep, but it's doable. Even without git, you will
still be able to use bdep-ci and bdep-publish with a bit of effort. We
have packages where upstream doesn't use version control at all (or at
least it's not publicly visible; for example byacc[2]).

>   - Build configurations appear to be stored in a sqlite database, not in a
> readable and editable text file.

It's a bit more nuanced that that: some information (usually the one
you don't want to edit manually) is stored in the SQLite database, while
things like compiler, options, etc that you have configured are stored
in plain text files that you are welcome to edit.

Continuing with the above example:

$ cat ../hello-clang/build/config.build

config.cxx = clang++
config.cxx.poptions = [null]
config.cxx.coptions = [null]
config.cxx.loptions = [null]
config.cxx.aoptions = [null]
config.cxx.libs = [null]
...

You can edit this file and, for example, change config.cxx.coptions to:

config.cxx.coptions = -Wall -Wextra -Werror

[1] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#proj-struct
[2] https://github.com/build2-packaging/byacc/