Re: On Boost and modules

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-04-11 12:57:37

On 11.04.24 11:44, Boris Kolpackov via Boost wrote:
>>    - 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.

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:

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

I find the use of <super_project_name> 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_at_[hidden])