search

bemanproject / exemplar

Example Beman project
Other
11 stars 16 forks source link

Add CMake preset support #17

Closed neatudarius closed 1 month ago

bretbrownjr commented 2 months ago

In my mind the use case behind this request is to make it easy to have simple commands to perform normal development tasks.

I think a first step here would be to define a small set (1-3?) of workflows to add to a presets file. It seems unlikely we'll be able to enumerate and then maintain all the combinations of builds and workflows that might be interesting. So let's avoid that impulse. To support all those use cases, we'll want to come up with a more robust approach.

So I think the next step for this issue would be to define that small set of workflows. A PR to add the presets file would be downstream of a design decision, but someone could submit a PR too, assuming they're confident in their design choices.

wusatosi commented 2 months ago

In #6, @mguid65 created a set of presets, would that be good starting point?

steve-downey commented 2 months ago

Presets are for the small set of defaults a developer is expected to use in the normal workflow. They aren't designed for the matrix of compilers, compiler versions, standard versions, sanitizer choices and so forth. For MSVC Debug/Release might be in presets since they're binary incompatible, for libstdc++ and libc++ debug is an uninteresting choice, except for the tradeoffs of getting accurate warnings from the optimization passes vs time spent on the optimization. There's never a reason for a developer not to have debug info included, the RelWithDebugInfo choice in CMake built in build types.

Since we're targetting standards proposals, most projects are going to need to target cutting edge or trunk compilers and may require std C++26 today, but probably at least C++20 to avoid twisting yourself into knots trying to implement the constraints as specified.

This is amplifying on what Bret said above.

neatudarius commented 2 months ago

@wusatosi , if you would like, you can also assign this issue to you.

camio commented 2 months ago

In #6, @mguid65 created a set of presets, would that be good starting point?

@mguid65's presets include gcc, clang, and msvc. All are debug and all use the Ninja generator. These all seem reasonable to me as convenient defaults for developers. I'd probably add sanitizer flags to these builds as well.

Another change I'd probably make is to use the "Visual Studio 17 2022" generator/x64 platform for the msvc build. This is more commonly used than Ninja for developers on that platform.

mguid65 commented 2 months ago

In #6, @mguid65 created a set of presets, would that be good starting point?

@mguid65's presets include gcc, clang, and msvc. All are debug and all use the Ninja generator. These all seem reasonable to me as convenient defaults for developers. I'd probably add sanitizer flags to these builds as well.

Another change I'd probably make is to use the "Visual Studio 17 2022" generator/x64 platform for the msvc build. This is more commonly used than Ninja for developers on that platform.

Which sanitizers and will they be separate presets or always enabled?

camio commented 2 months ago

Which sanitizers [should we enable] and will they be separate presets or always enabled?

All of them (assuming they can be all on at the same time) and I'm thinking they should always be enabled in these presets.

mguid65 commented 2 months ago

You cannot use asan with tsan at least in GCC.

wusatosi commented 2 months ago

Which sanitizers [should we enable] and will they be separate presets or always enabled?

All of them (assuming they can be all on at the same time) and I'm thinking they should always be enabled in these presets.

I don't think the majority of projects will need Thread Sanitizers, sanitizers do conflict with each other.

wusatosi commented 2 months ago

@wusatosi , if you would like, you can also assign this issue to you.

I would be happy to implement this. But I think I will wait for a bit for more discussion before implementing.

camio commented 2 months ago

Which sanitizers [should we enable] and will they be separate presets or always enabled?

Based on my read of the GCC documentation, omitting thread and hwaddress sanitizers will allow us to turn on most of the other ones. I think this would be a good default for a gcc preset. We can follow a similar train of thought for clang.

For thread heavy libraries, thread sanitizer may be a better default.

wusatosi commented 1 month ago

So I assume from current discussion, we should at least include:

matrix of gcc, clang, msvc (I will need help with that) debug build, with all sanitizer except thread and hwaddress enabled (-fsanitize=address, -fsanitize=pointer-compare, -fsanitize=pointer-subtract, -fsanitize=leak, -fsanitize=undefined. -fsanitize=shadow-call-stack omitted because it only supports aarch64).

This would imply we would want some single/ matrix of O3 release compile.

(if this is a sane starting point, I would be happy to take this issue).

camio commented 1 month ago

This looks like a good starting point. Thanks for taking it on! I have some MSVC experience so I can help there.

wusatosi commented 1 month ago

This looks like a good starting point. Thanks for taking it on! I have some MSVC experience so I can help there.

That would be really helpful! We can work on this once I finish with the pre-commit linting, was there a reason why #5 was abandoned? That pr seem to do most of the job here, just need to add in sanitizers.

camio commented 1 month ago

was there a reason why https://github.com/beman-project/exemplar/pull/5 was abandoned?

It was created to start a discussion and was effective at that. Beyond that, other tasks took priority for me.

wusatosi commented 1 month ago

@wusatosi , if you would like, you can also assign this issue to you.

Note that I do not have access to assign issue.

But #44 is open for discussion now! Please provide feedback.

steve-downey commented 1 month ago

Which sanitizers [should we enable] and will they be separate presets or always enabled?

All of them (assuming they can be all on at the same time) and I'm thinking they should always be enabled in these presets.

I don't think the majority of projects will need Thread Sanitizers, sanitizers do conflict with each other.

Thread and Memory sanitizers also need to be on for everything linked into a program, although probably not an issue here. Address and undefined behavior can be combined and are local in effect. I have seen them trigger the maybe-uninitialized warning on recent GCC.