Re: [boost] On Boost and modules

11 Apr 2024

      On 11.04.24 11:44, Boris Kolpackov via Boost wrote:
...
...
- bdep creates a / hierarchy.  I assume the
outer  directory is the package and the inner 
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 ,
so in practice I've got three levels:
//.
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.
I have been using the canonical layout for the purpose of following 
along with the Getting Started Guide. I realize that some aspects of 
this cane be changed, but others seemingly can't.

This is the layout I want:

   + builds <- not in version control
     + configuration1
     + configuration2
   + source
     + 
       + 
         + <project>.hpp
         + <project>.cpp
   +  <- in version control

I find the use of  useful to separate internal 
libraries and external libraries, and to prevent namespace pollution.  I 
use this include style:

   #include "super_project_name/project_name/project.hpp"

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.

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).
   - Build configurations are versioned.
...
...
- 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.
Yeah, I really don't like these <project>-<configuration> directories at 
the same level as the main project.  Hence the need to manually specify 
a different directory.
...
...
- 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.
I know I can, but I don't like losing "nice to have" functionality. 
Especially when I'm just getting started with Build2 and I don't know 
what that functionality is or how nice it is.
...
...
- 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
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.

-- 
Rainer Deyke (rainerd@eldwood.com)