Re: On Boost and modules

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-12 10:49:27

On 11.04.24 19:03, Boris Kolpackov via Boost wrote:
> Rainer Deyke via Boost <boost_at_[hidden]> 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 <project_name>-<configuration_name> 
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 
<project_name>/<project_name>/<project_name> 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_at_[hidden])