[build2] Recommended way to override build2 configuration CLI arguments

[Matthew Krupcale]

Hello,

I am trying to find the best way to override build2 configuration
arguments passed on the command line. For example, suppose that I have
a macro[1] which defines a default of `config.bin.lib=shared` so that
only shared libraries are built by default (a reasonable default on
Fedora). Then the user wants to override this CLI option for a
specific project (e.g. so that a library project can be statically
built and linked in order to bundle with the other project until it
can be separately packaged and un-bundled). This will fail:

$ # create some dummy projects
$ b create: proj-shared/,cc
$ b create: proj-static/,cc
$ # define our "macro"
$ config_default="config.bin.lib=shared"
$ # configure them accordingly
$ b configure: proj-shared/ "${config_default}" # [string]
config.bin.lib = shared # original: both
save proj-shared/build/config.build
$ b configure: proj-static/ "${config_default}" config.bin.lib=static
error: multiple amalgamation overrides of variable config.bin.lib

I have found some alternative methods relying on the different
variable_visibility[2] having different handling of overrides[3,4]. In
particular, I can do one of the following:

$ b configure: proj-static/ "${config_default}"
'%config.bin.lib=static' # [string] config.bin.lib = shared #
original: both
save proj-static/build/config.build

in which the normal visibility takes precedence over project
visibility and the overrides do not conflict with one-another but does
not get me the desired result, or,

$ b configure: proj-static/ "${config_default}"
'proj-static//config.bin.lib=static' # [string] config.bin.lib =
static # original: both
save proj-static/build/config.build

in which the scope visibility takes precedence over the normal
visibility, the overrides again do not conflict, and gets me the
intended result, but I do have to specify the project directory twice
(once as the target and once as the configuration scope override).

An alternative mechanism would be to run two `configure:` steps: one
with the default configuration, and then any overrides specified with
normal variable visibility. In this way the overrides will also not
conflict, since they also come from different scopes/sources. Thus,

$ b configure: proj-static/ "${config_default}" # [string]
config.bin.lib = shared # original: both
save proj-static/build/config.build
$ b configure: proj-static/ config.bin.lib=static # [string]
config.bin.lib = static # original: shared
save proj-static/build/config.build

My desire is to have the proj-static/build/config.build specify
`config.bin.lib=static` despite the first/default CLI value of
`config.bin.lib=shared`, and I would like to make this override using
a CLI argument rather than modifying the file directly. This way the
user will be able to build, install and test both projects in parallel
with their correct respective configurations:

$ b proj-shared/ proj-static/
$ b install: proj-shared/ proj-static/
$ b test: proj-shared/ proj-static/

Which of the above mechanisms is the recommended way to accomplish
what I desire? Have I missed something else?

Alternatively--and this may break some of the symmetry/consistency in
the current design to reject overriding the same variable multiple
times--we could allow only on the CLI to override options of the same
visibility / scope by simply taking the last value in said visibility
/ scope when parsing the CLI. Thoughts?

Best,
Matthew

[1] https://copr-dist-git.fedorainfracloud.org/cgit/mkrupcale/build2/build2.git/tree/macros.build2?id=0d795718552213fd60cd207b37a5e7d6270f3141
[2] https://git.build2.org/cgit/build2/tree/build2/variable.hxx?id=e0002617846755fb5f199f40a677e16d6f69e5ec#n100
[3] https://git.build2.org/cgit/build2/tree/build2/context.cxx?id=e0002617846755fb5f199f40a677e16d6f69e5ec#n723
[4] https://git.build2.org/cgit/build2/tree/build2/b.cxx?id=e0002617846755fb5f199f40a677e16d6f69e5ec#n1248