Re: [boost] On Boost and modules

On 11.04.24 19:03, Boris Kolpackov via Boost wrote:

Rainer Deyke via Boost writes:

...

Double quotes instead of angle brackets because the file I'm including is not from the standard library, but always with both super_project and project names.

Nothing prevents you from using <>-style inclusion for non-standard headers, but ok, every C++ developer has their unique style ;-).

I am well aware that common practice uses <>-style includes for non-standard headers. I just don't like to think of extension-less standard headers like <vector> as actual physical files on my disk, so I mentally separate standard headers from actual physical header files with a .hpp/.hxx/.h extension. (And in fact, I don't think the standard headers are /required/ to be actual physical files per the C++ standard, although in practice they almost always are.)

...

The important bits here that Build2 doesn't seem to like: - Builds go under the main project directory. One project, one top-level directory (with as many subdirectories as needed).

Yes, one of the somewhat "hard" rules in build2 is that you either build in source, or out of source, not kind-of-out-of-source (i.e., with the builds/ directory inside your project repository).

The main user-facing reason for this is that build2 is multirepo-first, meaning that we assume the user will work with multiple repositories simultaneously and often it will be convenient to share build configurations between them. As an example, consider another repository bar that you develop simultaneously and that depends on foo (pretty much the arrangement of the Boost libraries on GitHub before they are amalgamated). While you don't have to, it's normally convenient to initialize them in a shared build configuration. If your build configuration directories are inside foo/ and bar/, then it becomes asymmetrical and awkward.

Wait, build configuration directories can be shared between multiple repositories? The canonical - directory names led me to believe that each configuration build directory is tied to both a specific project and a specific configuration. Of course, it's somewhat common for me to have multiple checkouts of the same project side-by-side, and it would not be safe for them to share build directories.

Having said that, there is an escape hatch if you really want to keep you build directory inside your repository: don't make your repository root a build2 project/package root, instead pushing it one directory level deeper (this is also how we support multi- package repositories).

Yes, that's what I was alluding to in an earlier post about a // directory structure. It works, it's just hard to keep all those same-named directories straight. Especially when using a file browser that only displays the name of the current directory, not the full path.

While it's hard to recreate your structure exactly (because of another "hard" rule in build2, which is that a project/package root directory must be the same as the project/package name, so it cannot be source/ or libs/), but you can get pretty close:

That's good to know.

$ bdep new --type empty foo $ cd foo $ bdep new --package --lang c++,cpp --type lib,subdir=boost/foo libboost-foo

...

That's a relief, but the configuration options are stored with the build artifacts? That's awkward if I want the configuration options in version control while keeping the build artifacts outside.

There is a mechanism for that: you can save some pre-canned configurations in the version control and then load them when creating the build configurations.

Also good to know. -- Rainer Deyke (rainerd@eldwood.com)