[build2] Feature Request: Build2 Work Tree

[Boris Kolpackov]

This is my first pass to clarify some of the misconceptions and try
to understand what's this all about (after a couple of reads, I am
still very fuzzy).


Klaim - Joël Lamotte <mjklaim at gmail.com> writes:

> In all these cases and in some previous complex projets, the best
> organization recommended if I had used build2 to make them would have
> been to make each specific tool/library it's own build2 project, then
> group these in repositories separated as fine-grained as possible (the
> usual would be a library and related executable are isolated in their
> repositories).

This is not quite what we recommend. There is nothing wrong with
grouping related packages in a single project repository and this
approach is supported by build2:

https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-dev-multi


>  - 1.1. A newcomer setup a directory, let's call it a "work tree",
> with all the projects related to the team fetched, configured and
> built;

So basically clone a bunch of repositories and initialize them with
bdep-init, creating a bunch of configurations in the process.


>  - 1.2. Attempt to change the current branch of all the projects to
> the same branch name (all to `master`, or all to `develop` would be
> the most common);

Ok, sounds like purely VCS operation.


>  - 1.3. Define a new configuration, then make all the projects of the
> directory use and build with that configuration (should also be easy
> with several configurations added);

Ok, so basically a bdep-init -C call followed by a bunch of bdep-init -A.


>  - 1.4. Launch all the tests of all the projects (one build2 project
>  at a time);

Ok, so a bunch of bdep-test calls.


>  - 1.5. Add/clone new repositories to the directory and make them all
> build with all the configurations already existing;

Ok, a bunch of bdep-init -A calls (the same project but multiple
configurations).


>  - 1.6. Define the same package repository(ies) for all the
> configurations of the directory (so that the dependencies all come
> from the same repositories);

Not sure what this means. Are you talking about a manual bpkg-rep-add
for each build configuration?


>  - 1.7. When a dependency is actually one of the projects,
> automatically makes all the configurations use the local version
> instead of the one retrieved from the package repositories;

This is achieved by simply initializing  it (bdep-init) in the
respective configurations. So this is effectively the same as 1.5.


>  - 1.8. Change a dependency version in all configurations (implicitely
> changing that version for all the projects currently being worked on);

Ok, so bdep-sync in the dependency upgrade/downgrade mode for all the
build configurations.


So far it sounds like all of these boil down to a for-loop either
over the list of configuration or the list of projects. Am I about
right?


> ### 2.1 Git Sub-Modules to handle Work Trees.
> 
> I believe this is the solution used by `build2` team [...]

No, we don't use git submodules for that.