<div dir="ltr"><div><br>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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Mar 2024 at 14:17, Boris Kolpackov via users <<a href="mailto:users@build2.org">users@build2.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> I'll read through the documentation given this evening when I'm free but I'm<br>
> getting the impression build2 doesn't support sharing configurations and the<br>
> expectation is that either the project maintainers build scripts to allow<br>
> for the sharing/setup of configurations or individual developers are<br>
> expected to manually set them up when they first deploy.<br>
><br>
> Is that impression accurate?<br>
<br>
I think the more accurate way to state this is that build2 currently<br>
provides a low-level'ish mechanism (in the form of config.config.save<br>
and config.config.load) that can be used (and I believe are already<br>
used) to have pre-canned build configurations.<br>
<br></blockquote><div><br></div><div>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: <a href="https://github.com/build2-packaging/imgui/tree/main/build-config">https://github.com/build2-packaging/imgui/tree/main/build-config</a><br>These files are loaded on github's ci using `bdep init ... config.config.load=...` as Boris explained before: <a href="https://github.com/build2-packaging/imgui/blob/main/.github/workflows/build2.yml#L45">https://github.com/build2-packaging/imgui/blob/main/.github/workflows/build2.yml#L45</a></div><div><br>The `config.load.load/save` feature is the closest thing to CMake's "preset" feature for example, if you're familiar with that Michael?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> If so, can you help me understand the rationale for not providing<br>
> strong support for the sharing of configurations?<br>
<br>
The main rationale is that the authors of build2 don't have a strong<br>
need for something like this and, as a general rule, are reluctant to<br>
add features without first understanding the use-case well.<br>
<br>
For example, when I configure builds of a new project, I don't feel<br>
a strong need to use something pre-canned. I would normally make<br>
a default configuration that uses the latest GCC that I have on my<br>
machine, I will pass `-g -Wall -Wextra -Werror` as the compiler<br>
options and also usually enable the address sanitizer. I will then<br>
add another build configuration for Clang and maybe for the MinGW<br>
GCC cross-compiler if I care about Windows in this project.<br>
<br>
But I am also happy to accept that I may be the exception rather<br>
than the rule or that a different type of project and/or team may<br>
require a different approach. So we are willing to listen and add<br>
better support for pre-canned configurations if it makes sense.<br>
But you will need to help us better understanding the use-case.<br>
In particular, can you give concrete examples of what you would<br>
want to share and what, in your opinion, "stronger" support for<br>
this might look like?<br>
<br></blockquote><div><br></div><div>Just to add my point of view on this discussion: in my experience,<br><br>- 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.<br>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: <a href="https://github.com/build2/build2/issues/11">https://github.com/build2/build2/issues/11</a><br><br>- Projects that are not open-source or dependent on non-trivial dependencies (as tracked by <a href="https://github.com/build2/build2/issues/202">https://github.com/build2/build2/issues/202</a>) 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.<br><br>- 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:<br>    - 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.<br>    - 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<br>    - 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.<br>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.<br><br>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.<br>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. <br><br>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: <a href="https://github.com/build2/HOWTO/blob/master/entries/add-action-targets.md">https://github.com/build2/HOWTO/blob/master/entries/add-action-targets.md</a><br>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.<br>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).<br>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.<br><br>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.<br><br></div><div><br></div></div></div>