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

Beman Project Development
1

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 and Build instructions don't work · Issue #31 · beman-project/Optional26 · GitHub. If not obvious, we should decide a short-term approach (e.g., kept until after CppCon - Dietmar suggested to have something simple and clear).

2

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 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 for several years now, for reference. carbon-lang/.pre-commit-config.yaml at trunk · carbon-language/carbon-lang · GitHub

3

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.

1 Like
4

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.

5

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

6

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.

1 Like
7

Please take a look here:

image
image700×264 11.4 KB

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 you can see 2 helper scripts, check scripts/README.md 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
image1782×1534 328 KB

8

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:

      "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?