[build2] question regarding build configurations

[Boris Kolpackov]

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

> I'm confused.  I did technically reply to the email but removed the contents
> and updated the subject.  How is your mailing list associating this email
> with my previous email?

When you reply to an email, most email clients will add the In-Reply-To
header with Message-ID of the message you are replying to. This is how
mailing list software (like mailman) and mail clients (like mutt)
implement email threading. You can see the result here:

https://lists.build2.org/archives/users/2024-March/thread.html


> > 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.
>
> I feel like my mental model is off somewhere.  To me "build configuration
> directory" and "build configuration" are synonymous in that the directory is
> the storage area for the build configuration but otherwise is the same
> thing.

On the conceptual level, a "build configuration" is a collection of
settings (compiler name/path, compile options, etc) that you use to
build your project(s) and its dependencies. Necessarily the result
of such a build for different configurations must be placed into
separate directories, which, more precisely would be called something
like "build configuration output directory", but that's a mouthful and
since the mapping is 1-to-1, we call both a "build configuration",
adding "directory" if necessary to disambiguate.


> I'll read through the documentation given this evening when I'm free but I'm
> getting the impression build2 doesn't support sharing configurations and the
> expectation is that either the project maintainers build scripts to allow
> for the sharing/setup of configurations or individual developers are
> expected to manually set them up when they first deploy.
>
> Is that impression accurate?

I think the more accurate way to state this is that build2 currently
provides a low-level'ish mechanism (in the form of config.config.save
and config.config.load) that can be used (and I believe are already
used) to have pre-canned build configurations.


> If so, can you help me understand the rationale for not providing
> strong support for the sharing of configurations?

The main rationale is that the authors of build2 don't have a strong
need for something like this and, as a general rule, are reluctant to
add features without first understanding the use-case well.

For example, when I configure builds of a new project, I don't feel
a strong need to use something pre-canned. I would normally make
a default configuration that uses the latest GCC that I have on my
machine, I will pass `-g -Wall -Wextra -Werror` as the compiler
options and also usually enable the address sanitizer. I will then
add another build configuration for Clang and maybe for the MinGW
GCC cross-compiler if I care about Windows in this project.

But I am also happy to accept that I may be the exception rather
than the rule or that a different type of project and/or team may
require a different approach. So we are willing to listen and add
better support for pre-canned configurations if it makes sense.
But you will need to help us better understanding the use-case.
In particular, can you give concrete examples of what you would
want to share and what, in your opinion, "stronger" support for
this might look like?