[build2] question regarding build configurations

[Michael Reiland]

> Please don't send a new question by replying to an existing message since this messes up threading.

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?  I looked through the headers of the raw message and nothing jumped out at me but it would be helpful for me to understand.


> 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.

That's what I was after, I figured there was a way to recreate them I just wasn't seeing how, thanks for the info.


> 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.

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?  If so, can you help me understand the rationale for not providing strong support for the sharing of configurations?

-- 
  Michael Reiland
  dev at michaelreiland.net

On Tue, Mar 12, 2024, at 8:39 AM, Boris Kolpackov wrote:
> 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