I have entertained this idea with @bretbrownjr .

You can read our discussion here: #105 (comment) and #105 (comment) .

I think this is a good short-term patch, but I think we might need to essentially redesign presets to fit current combination explosion.

I am in support of this change, but I will leave the decision to @bretbrownjr and @camio .

I saw @camio commenting earlier that we broke his workflow, and I think this minimal solution is OK for out of the box use for someone kicking the tires, or in one of our common cases.

Presets just aren't designed to support all the possible combinations, though. They're for a small-ish set for a group who builds things in a very consistent way, sharing the same workflow, with a small set of tools involved.

That is a very common situation. But it's really not for the matrix explosion of a public C++ project where you want to check all the things all the ways.

We might be able to use condition: blocks and $env{<variable-name>} to provide some ways of injecting options into the presets files, but the fact that it's not obvious how to do this suggests that it's not going to be well supported? I've never used presets in anger, and we've not adopted them at Bloomberg, sticking with our own workflow tools and configuration management strategies, which are unfortunately far too tied to our environment to be usefully released.

Except FetchContent out of the box also breaks other workflows. I started this packaging effort a few months ago because my out of the box experience wasn't working.

I'm not opposed to some branded workflows obviously supporting FetchContent. I don't agree that it's a (singular) sensible default though.

The reasons Bloomberg has been slow to adopt presets have more to do with the design limitations of presets than any in-house tech conflicts.

Namely:

• Unbounded complexity when configuring all interesting build flavors

• The need to maintain preset files in every. single. repo. The tech is nowhere near settled enough to land one and never touch it for five plus years. Clang is still coming out with new sanitizers.

• The biggest headaches have to do with dependency management, not CMake build workflow defaults. And good solutions to dependency management alleviate a lot of the pain points that presets help with (like better defaults).

I'm supportive of this PR. There are tradeoffs for whatever default we choose, but a FetchContent default has a fully known dependency set which makes issues at first-exposure (like #141) much less likely.

I've also approved for at least the short term due to the regression. @bretbrownjr are we ok to fix and open another issue to re-evaluate?

Note: I fixed the conflicts and merged with main. If all tests will pass, I will merge this PR as now it has strong consensus.