# Possible high priority topic: short/long term approach for build interface

**URL:** <https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153>\
**Category:** Beman Project Development\
**Created:** [July 18, 2024, 2:11pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153 "2024-07-18T14:11:20Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![neatudarius](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/neatudarius/32/70_2.png) [@neatudarius](https://discourse.bemanproject.org/u/neatudarius)\
**Post date:** [July 18, 2024, 2:11pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/1 "2024-07-18T14:11:20Z")

</div>

The Beman Standard imposing using CMake, but not specifing how we actually expose build and run commands to our users.

Starting from Beman.Optional26, which right now exposes only CMake vanilla commands, we should discuss 1) if we want to keep only this interface or 2) to offer make/script/etc based wrappers. Regardless of outcome (may we’ll have both), I think we should document only one straightforward approach in root README. My opinion is that we should pick a single interface and use in README/examples/CI jobs.

Note that this thread directly impacts [Build wrapper vs CMake vanilla commands · Issue #35 · beman-project/Optional26 · GitHub](https://github.com/beman-project/Optional26/issues/35) and [Build instructions don't work · Issue #31 · beman-project/Optional26 · GitHub](https://github.com/beman-project/Optional26/issues/31). If not obvious, we should decide a short-term approach (e.g., kept until after CppCon - Dietmar suggested to have something simple and clear).

---

<div class="post-metadata">

**Author:** ![Sdowney](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/sdowney/32/73_2.png) [@Sdowney](https://discourse.bemanproject.org/u/Sdowney)\
**Post date:** [July 18, 2024, 6:01pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/2 "2024-07-18T18:01:33Z")

</div>

re: tool versions - It’s too bad there isn’t an existing CppPI, but we might considering leveraging PyPi. We probably will need to anyway for linting tools? PyPI has cmake, ninja [w/jobserver patch], clang-format, clang-tidy, as well as cmakelint, cmake-format, and others. The big advantage is that by installing in a virtual env the project doesn’t have to rely on OS provided tools or require local installs that have cross-project impact.

WIP: but see [GitHub - steve-downey/expected: std::expected implementation for further work](https://github.com/steve-downey/expected) where I’m implementing std::expected in order to propose std::expected\<T&, E\> in D3350R0 - next mailing.

Biggest downside is that building a dev environment is a lot of machinery. Upside is that people who want other tooling can compare a working state, and the CI and dev can more closely mirror each other.

The pre-commit framework also can help with consistency in various lint tools.

I’m borrowing from python because they have similar forces where there are a variety of tools used and the ecosystem doesn’t have a ‘one true way’, unlike Rust, Go, or to a lesser extent Java.

Carbon-lang adopted [pre-commit](https://pre-commit.com/) for several years now, for reference. [carbon-lang/.pre-commit-config.yaml at trunk · carbon-language/carbon-lang · GitHub](https://github.com/carbon-language/carbon-lang/blob/trunk/.pre-commit-config.yaml)

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [July 18, 2024, 7:49pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/3 "2024-07-18T19:49:36Z")

</div>

> [@neatudarius](#):
>
> to offer make/script/etc based wrappers

My understanding is that we currently have a single command to build and test with the system C++ installation, `cmake --workflow --preset system`. This looks ergonomic enough to obviate the need for a wrapping script IMO.

---

<div class="post-metadata">

**Author:** ![Sdowney](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/sdowney/32/73_2.png) [@Sdowney](https://discourse.bemanproject.org/u/Sdowney)\
**Post date:** [August 2, 2024, 2:14am UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/4 "2024-08-02T02:14:05Z")

</div>

Cmake presets have terrible scaling problems with a matrix of options. You have to spell out in a distinct stanza each combination of compilers, architecture, build modes, testing options, and so on. It’s designed to make the default path simple, but suffers from combinatorial explosion for the sort of multi platform development required to support portable libraries.  
Especially since the system compiler for common platforms can be old.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [August 9, 2024, 10:30pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/5 "2024-08-09T22:30:06Z")

</div>

> [@Sdowney](#):
>
> Cmake presets have terrible scaling problems with a matrix of options.

Are you thinking it’d be best to include only a few presets representing the most common use-cases? Maybe for developers? I don’t know that there will be that many users who will want to download and build directly (without using add\_subdirectory, FetchContent, or a package manager).

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [August 12, 2024, 4:39pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/6 "2024-08-12T16:39:39Z")

</div>

I think for now the right balance is to pick a few build workflows to intentionally support. We can also consider it a bug to break any other workflow that we’re not intentionally testing against.

Long term, I think it will be hard to get the Beman Standard to detail all the ins and outs of all of the workflows we might want. I expect we’ll need tools of some sort to help with mixing and matching all the choices we make when we build things.

---

<div class="post-metadata">

**Author:** ![neatudarius](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/neatudarius/32/70_2.png) [@neatudarius](https://discourse.bemanproject.org/u/neatudarius)\
**Post date:** [August 12, 2024, 5:04pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/7 "2024-08-12T17:04:59Z")

</div>

Please take a look here:

> **[GitHub - beman-project/Optional26: Beman.Optional26: \`std::optional\` extensions...](https://github.com/beman-project/Optional26)**
>
> Beman.Optional26: \`std::optional\` extensions targeting C++26

 ![image](https://canada1.discourse-cdn.com/flex029/uploads/boost/original/1X/1aeb064aa8c59cb069aaf3afe6d515734a0584f9.png)

These are the current build instructions for Beman.Optional26.

In experimental PR [Improve local and CI flows by neatudarius · Pull Request #26 · beman-project/Optional26 · GitHub](https://github.com/beman-project/Optional26/pull/26) you can see 2 helper scripts, check [scripts/README.md](https://github.com/beman-project/Optional26/pull/26/files?short_path=25b96aa#diff-25b96aa16f8b9f68c692d0db061713707e9cfc67b296e0ea30908928fb3ffcd6) for a possible unified interface. I am OK to always build with CMake vanilla commands, to force user to understand side effects - if they don’t care, they can use CMake presets! But for tests and linting, I would like a solution which allows me to integrate similar tools and provide so many custom options to run test or lint the code (local and CI flows):

 ![image](https://canada1.discourse-cdn.com/flex029/uploads/boost/original/1X/b95c7cc0fecfdcc826954f5dfbda326029ee7a18.png)

---

<div class="post-metadata">

**Author:** ![linusboehm](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/linusboehm/32/84_2.png) [@linusboehm](https://discourse.bemanproject.org/u/linusboehm)\
**Post date:** [August 13, 2024, 2:05pm UTC](https://discourse.bemanproject.org/t/possible-high-priority-topic-short-long-term-approach-for-build-interface/153/8 "2024-08-13T14:05:57Z")

</div>

just had a brief look at the build. In the `CMakeLists.txt` it specifies `cmake_minimum_required(VERSION 3.27)` and in the `CMakePrest.json`:

```json
      "cmakeMinimumRequired": {
        "major": 3,
  ▎ "minor": 26,
        "patch": 2
      },

```

1. Should the cmake minimum versions match between the two files?
2. Are you using any features of those versions, or would an older version suffice?