[build2] question regarding build configurations

[Boris Kolpackov]

Please don't send a new question by replying to an existing message
since this messes up threading. See Posting Guidelines for details:

https://lists.build2.org

Michael Reiland via users <users at build2.org> writes:

> hello-gcc and hello-clang are siblings of the hello directory.  The hello
> directory is a git repository so it's meant to be checked into version
> control.
> 
> What is the expectation for hello-gcc and hello-clang in terms of version
> control and sharing amongst multiple developers on a team?

You normally don't want to keep build configuration directories like
this in the version control repository since they will contain build
artifacts (object files, binaries, etc).

What you are probably after is sharing the configuraton (compiler
options, etc). The recommended way to do this is to extract it into
a file, check it into the version control repository, and then load
this file later.

For details on this mechanis, see:

https://build2.org/release/0.12.0.xhtml#config-export-import

As an example (continuing with hello from the introduction), once
you have created hello-gcc from scratch for the first time, save it:

$ b configure: ../hello-gcc/ config.config.save=gcc-config.build

Then, when you want to re-create the same configuration, load it:

$ bdep init -C ../hello-gcc @gcc cc config.config.load=gcc-config.build


> in the man pages for bdep-config it refers to a "build configuration set",
> with the ability to add and remove configurations from it.  This seems like
> a project specific data but I couldn't find where this information is
> stored.  In addition, bdep config list describes a path output for the
> configuration, which implies the configuration set knows the filesystem
> path.
>
> if I clone a fresh copy of a build2 project, how do I recreate the build
> configurations if they're not checked into source control?  I tried deleting
> the build configuration directory to see if I could get the directories to
> be recreated from the project itself but was unable to do so.

Generally the configuration set will vary from developer to developer.
For example, I am on the latest Debian sid and have GCC 13 and Clang 18.
Someone else who collaborates with me could be on Windows with MSVC.
Though it is also plausible to have a very controlled and homogeneous
environment where every developer uses exactly the same operating system,
compiler version, etc. And in such cases I can see how it can be desirable
to re-create the "canonical" set of configurations automatically.

Currently, the best way to achieve this would be with a script (potentially
in combination with the mechanism described in the previous answer). One
potential improvement over this would be to use the "glue" buildfile
instead (which is customarily found in the root of a multi-package
repository). For background on this approach see:

https://github.com/build2/HOWTO/blob/master/entries/add-action-targets.md