[build2] Build2 configuration for component based projects

[Boris Kolpackov]

Hi,

Sorry for the delay in getting back to you. I wanted to implement a
couple of missing bits before replying ;-).


asatsuyu at tutanota.com <asatsuyu at tutanota.com> writes:

> I would like to use build2 for building a project whose structure is
> slightly different from the one introduced in the cppcon talk given
> by Boris in 2016. After simplification, the project tree would look
> like the following:
>  
>  project
>  ├── bld
>  │   ├── cfg_A
>  │   │   └── build
>  │   │       ├── bootstrap
>  │   │       │   └── src-root.build
>  │   │       └── config.build
>  │   └── cfg_B
>  │       └── build
>  │           ├── bootstrap
>  │           │   └── src-root.build
>  │           └── config.build
>  └── src
>      ├── build
>      │   ├── bootstrap.build
>      │   └── root.build
>      ├── buildfile
>      ├── cde
>      │   ├── cde_XXX.cpp
>      │   ├── cde_XXX.hpp
>      │   ├── cde_XXX.t.cpp
>      │   ├── cde_YYY.cpp
>      │   ├── cde_YYY.hpp
>      │   └── cde_YYY.t.cpp
>      └── efg
>          ├── efg_ZZZ.cpp
>          ├── efg_ZZZ.hpp
>          └── efg_ZZZ.t.cpp

While it will work, this structure is not "canonical". Practically, this
means that it won't "fit" with other nice features and usage scenarios
that expect the canonical/"parallel" structure like this:

bld/cfg_A/
bld/cfg_B/
project/src/

For example, in your setup you won't be able to package project/ as a
bpkg package.

Also, using .t as a second level extension is asking for trouble (at
least in build2). Again, you can make it work, it's just you will have
to specify full extensions everywhere explicitly. So I would suggest
that you use something else, e.g., efg_ZZZ-t.cpp.


>  The code under the src directory is organized in "components" and each
>  "component" is made up of three files (this is rather common I guess):
>
>  - One .hpp file which contains function/struct/class declarations and
>    inline/template functions implementations.
>  - One .cpp file which contains the implementation of the non inline/
>    template functions declared in the associated .hpp file.
>  - One .t.cpp file which contains the test driver with a function for
>    the function/struct/class declared in the associated .hpp file. [...]
>  
>  The description is probably oversimplified but that would already be
>  nice to get the following tasks to work without having to modify the
>  buildfile for each newly added component.
>
>  - build the new/outdated object files (XXX.o and XXX.t.o)
>  - build the new/outdated/failed test driver binary (XXX.t), run them
>    and report failures if any.

Yes, you can do that. If you get the latest staged version of build2[1],
then the following buildfile should do the trick (note that it assumes
we are using the -t test naming instead of .t):

for t: $path_search($src_base/**-t.cpp)
{
  # Test directory relative to src_base.
  #
  dir  = $path.leaf($path.directory($t), $src_base)

  # Test name without -t.cpp.
  #
  name = $regex.replace($path.base($path.leaf($t)), '-t', '')

  ./: $dir/exe{$name}
  $dir/exe{$name}: $dir/{hxx cxx}{+$name*}
}

cxx.poptions =+ -I"$src_root"

exe{*}: test = true

In fact, I've packaged a complete working project based on the above
outline for your reference:

https://codesynthesis.com/~boris/tmp/build2/components.tar.gz

[1] https://stage.build2.org/0/

Boris