[build2] How to achive a mini-monorepo project structure

Boris Kolpackov boris at codesynthesis.com
Fri Jan 28 08:02:43 UTC 2022


Matt Armstrong via users <users at build2.org> writes:

> I have a small but rapidly changing exploratory project, with a small
> number of libraries and a small number of executables.  It is unlikely
> that anybody else will ever use this code.  For this reason, I keep it
> all in one git repository.
> 
> In other build systems, I have easily expressed this as a kind of
> "mini-monorepo" structure: one version control repository, N libraries,
> N binaries.

Let me state for completeness that in build2 there are two ways to
arrange this: as a project with multiple packages or as a project
with multiple source subdirectories. While the multiple packages
approach has some management overhead (e.g., you have to keep track
of inter-package dependencies in their manifests, etc), it also has
a number of benefits (e.g., you will be able to CI individual packages
and, of course, easily reuse one of the libraries in another "mini-
monorepo").

(Actually, there is also an in-between approach where you have a
number of build system-level subprojects, but let's not complicate
things; you can read more on this[1] if you are interested.)

As I understand it, you are interested in the multiple source sub-
directories approach so below I will focus on that (I believe the 
multiple packages approach is covered sufficiently well in the 
introduction).


> In build2, I have failed to express this project structure after two
> attempts of carefully reading through the tutorial and honestly trying.
> I must be missing something.
>
> [...]
>
> One thing I'll note is that the
> https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml
> does not cover this use case.  I can't find coverage of how one target
> is built from another across directories.  There is great coverage for
> producing and consuming packages, and for working with single-directory
> packages, but multi-directory packages are thin.

Yes, true, this is actually covered in the build system manual[2]. I
think it makes sense to at least add a note in the introduction. Maybe 
I should also add a HOWTO[3] entry on this?


> My repro is similar to the one in that issue, but uses --source instead
> of --project:
> 
> ```
> $ bdep new -l c++ -t bare hello
> $ cd hello
> $ bdep new --source -l c++ -t lib libhello
> $ bdep new --source -l c++ -t exe hello
> $ bdep init -C @gcc cc config.cxx=g++
> ```
> 
> If I instead change `hello/buildfile` to look like this:
> 
> ```
> libs = libhello%lib{hello}
> #import libs += libhello%lib{hello}
> 
> exe{hello}: {hxx ixx txx cxx}{**} $libs testscript
> 
> cxx.poptions =+ "-I$out_root" "-I$src_root"
> ```
> 
> I get the same error.
> 
> How can I teach b that hello/buildfile may use libhello from
> libhello/buildfile?

We use import to get targets from other projects. Within the same
project, we just include the buildfile that declares the target and 
use it directly (see [2] for details):

include ../libhello/ # Include lib{hello}.

exe{hello}: {hxx cxx}{**} ../libhello/lib{hello}

Alternatively, you can use project-local importation discussed in [4].
This can be especially attractive if you have a regular target/directory
naming structure and can implement a generic export stub that doesn't
need to be updated every time you add another library. For example, if
for every library target in the lib{hello} form you know that it resides
in the libhello/ subdirectory of your project, then you can have something
like this for your export.build:

if ($target_type($import.target) == 'lib')
{
  d = [dir_path] $out_root/"lib$name($import.target)"

  $d/
  {
    include ./
  }

  export $d/$import.target
}

[1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro-subproj

[2] It is first covered in a note at the end of:

    https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro-dirs-scopes

    And then discussed some more in:

    https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro-import

[3] https://github.com/build2/HOWTO/

[4] https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro-import



More information about the users mailing list