Add CMakePresets.json#5
Conversation
Reduces the number of steps to build and test. This is incomplete as the .github/workflows was not updated to use it. The intent is for this commit to generate discussion about moving in this direction.
| @@ -0,0 +1 @@ | |||
| .build No newline at end of file | |||
There was a problem hiding this comment.
I'm using build without a "." in bemanproject/beman#12. One of us should change for consistency.
There was a problem hiding this comment.
I tend to use build in my own projects, but I also prefer building entirely out of tree. However, seeing .build it occurs to me that it will basically never collide with any meaningful artefact in the repository, so a point in its favor?
| @@ -0,0 +1,52 @@ | |||
| { | |||
| "version": 6, | |||
| "cmakeMinimumRequired": { | |||
There was a problem hiding this comment.
I had to go update my cmake to test build the project. We shouldn't be bound by, for example, the version shipped in Ubuntu 20.04, but do we want to require current cmake as of when the commit was done?
Not a major problem, but if we want people to use current dev tools we might want to link to their instructions on where to get them.
There's a good chance we'll be requiring unreleased C++ compilers, in any case. So an advanced set of tools is something people will need to figure out how to install.
There was a problem hiding this comment.
We'll want CI for these builds. Given that, I think there's a pretty clear implicit requirement that we have a lowest common denominator version of each build tool, including CMake. And I believe using the CMake naturally provided in those environments (like a cmake package) is appropriate compared to downloading binaries or building cmake from source.
As far as Ubuntu goes, the new 24.04 LTS should have a new enough CMake for the Make lists.txt in this project.
steve-downey
left a comment
steve-downey
left a comment
There was a problem hiding this comment.
I have more experience with toolchain files rather than presets. How composable can we make presets? We're probably going to need to support a lot of dimensions in the build matrix. That is, a few different compilers, build types (Debug, RelWithDebInfo, etc), disjoint sanitizer choices, warning level choices, and so on, to support both reuse of the package and developer workflows.
Toolchain files do have some external composability issues, but at least between clang and gcc, it's not terrible to compose them externally, and some of the choices can be expressed as build types. For example having an ASAN type that also turns on ubsan, and uses -O2 or 3 so any ub is visible to the sanitizer.
|
I think creating presets for a small number of developer-facing workflows makes sense. Steve is correct that presets files have a hard time really supporting the full space of possible build configurations. Probably we're going to have to have some discussions and innovate a bit on ways to make development workflows trivial while keeping the files in this project focused on details specific to this project (like project structure) and free of CMake ergonomics per se (like how to do a CMake coverage build). I think it's fine to value developer ergonomics to keep people productive for now. Steve brought up some approaches we can evaluate as a group going forward. |
|
I think there might be a place for presets, but this PR seems to have lost momentum. If someone else wants to revisit presets later, another PR or issue makes sense. |
Quick fix for `Compute Image Name`
4 participants
Reduces the number of steps to build and test. This is incomplete as the
.github/workflows was not updated to use it.
The intent is for this commit to generate discussion about moving in
this direction.