[build2] question regarding build configurations

Wed Mar 13 14:43:29 UTC 2024

Hi, I'll try to add some of my pov below, and give some pointers to some
issues already tracking some of the related subjects.

On Wed, 13 Mar 2024 at 14:17, Boris Kolpackov via users <users at build2.org>
wrote:

>
> > 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.
>
>
There are examples of such "pre-canned" configuration files usage in some
of the packages handled by the community. The best example that comes to
mind is `imgui` packages which needs to be built with the github ci system
because of dependencies that are not always available on the build2 ci:
https://github.com/build2-packaging/imgui/tree/main/build-config
These files are loaded on github's ci using `bdep init ...
config.config.load=...` as Boris explained before:
https://github.com/build2-packaging/imgui/blob/main/.github/workflows/build2.yml#L45

The `config.load.load/save` feature is the closest thing to
CMake's "preset" feature for example, if you're familiar with that Michael?

>
> > 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?
>
>
Just to add my point of view on this discussion: in my experience,

- All other build systems I used (except `make`, includes scons, cmake,
msbuild (without cmake), and some custom build-systems) provided some
default configuration under a given name, usually with the toolchain and
"debug" or "release" in the name, OR at least a way to build such preset of
configuration specific to your project or company. This builds
expectations, obviously, when trying another build system. I suspect my
experience is similar to many in that domain.
The `config.config.load/save` feature allows at least to create and keep in
the project such a setup. As for the pre-made configurations,  we did
discuss that already and there is an issue to track the feature:
https://github.com/build2/build2/issues/11

- Projects that are not open-source or dependent on non-trivial
dependencies (as tracked by https://github.com/build2/build2/issues/202)
cannot benefit from build2's CI and have to set up their own CI somewhere,
which needs to always use the same required configurations. It's helpful to
have simple ways to specify the configurations to test and keep them in the
project's sources (config.config.load/save feature helps with that) if they
are very special for that project (usually for applications projects).
Often, just the default-provided "debug" and "release" configurations are
enough for a project, given a specific toolchain and target platform.

- While it might work for a few, having to remember all the flags
necessary for every compiler to use with various configurations (usually at
least for debug infos and optimized separately, but also potentially with
sanitizers or various toolchains) is simply unmanageable in most classic
situations including:
    - introduction of a new developer to an existing project: ideally the
dev just clone the project, run a command to configure and build+test.
Ideally these last 3 steps would be done in 1 command, which is what I
setup always in my own projects.
    - a dev already familiar with the project but they need to make a new
setup (new machine or whatever) -> same case as new developer on an
existing project
    - creating a new project: being able to setup manually the default
debug and release/optimized build configurations in one command avoids
losing time on the details.
In all these scenarios, if I had to manually remember all the flags I would
lose a lot of time and also probably make a lot of mistakes.

Note that applications projects (or end-user projects) are, in particular,
required to have specific build configuration that needs to work to be able
to build and publish the installable package. Libraries I guess are a bit
different in that pre-defined configurations are only useful to guarantee
that at least some specific configurations do work, but most users will
probably try to use them in untested configurations specific to their
use-case.
I have also worked on libraries which were designed to work for robotics,
which implied specific configurations for specific platforms, in addition
to the usual desktop ones to be able to build tools on desktops. In that
context, every new projects still had to build for specific configurations
(for the robots at least) and every software was tested on exactly the same
configurations. So basically it was similar to having a set of pre-defined
files specifying configurations and sharing that with all the projects,
requiring them to always have to build+tests successfully on at least
these.

In my current biggest personal (as in I'm deciding everything myself, no
company constraints)  project using build2, I used (or abused) the ad-hoc
scripting feature using the technique described there:
https://github.com/build2/HOWTO/blob/master/entries/add-action-targets.md
At the moment, after cloning my project from scratch, I can just `b
run{init-configs}` which will create the build2 config directories for me
automatically, toolchains varying depending on if I'm running a Windows or
Linux system when I launched that command. The configurations to setup are
pre-defined for that project (which is a game, so an application, and it's
not open-source). Even better: I can run `b run{editor}` to initialize the
configurations, build in one specific configuration that's the most
important for users on my current platform, run the tests, install in a
pre-defined directory and run the editor program of the game. I also have
`b run{game}` which does the same but runs the game instead of the editor.
Which means that a newcomer can git clone the project and `b run{game}` and
dont have to know which configurations are needed for that project as it's
already specified by the project. That's the ideal experience, because
usually people who wanting to work on a project admittedly want to work on
the actual code, not the scripts and configurations of how it's built. (and
a lot of build2 features helps with that).
Making sure the project is build/testable in one command is something I
have always done in all my projects because I often have to change machine,
or have to work on alternative versions of the same program. That also
helps a lot with setting up custom CIs. And that always requires
pre-defined configurations.

My xp is a small datapoint and has to be taken as such, but hopefully it
will help reach an understanding of what experience people not used to
build2 are usually expecting from such a tool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20240313/84c0582c/attachment-0001.html>