binary build dir in CMakePresets.json

[davidhunter22]

Currently the CMakePresets.json contains the following

    {
      "name": "ci-build",
      "binaryDir": "${sourceDir}/build",
      "hidden": true
    },

The binaryDir here forces the build to go into the directory build in the source tree. I think this is a very bad idea.
Maybe for CI builds this is OK as you may spin up a totally new environment for every build but if you are building local copies
they can clash. For instance you use WSL and want to build a GCC and a VS build using the same source tree. This is how I ran
into this.

It is noticeable that in BUILDING.md all the examples contain the -B flag

cmake -B build --preset=test-msvc

So the -B is used to override the binaryDir in the CMakePresets.json.
I suspect the binaryDir in the CMakePresets.json is there because it used to be a required field.
I would suggest removing the binaryDir which means by default the build tree goes into the directory where you are running cmake which is what most people probably expect. You can always still override this on the command line using -B.

An alternative would be to add CMakePresets.json items for command line builders that don't inherit ci-build. The downside of this is that they might drift apart, say by flags, from the ci-* presets which are used by CI build.

[GabrielDosReis]

I would suggest removing the binaryDir which means by default the build tree goes into the directory where you are running cmake which is what most people probably expect.

I agree. Would you mind preparing a PR for this?

CC: @friendlyanon who contributed the initial preset file.

[friendlyanon]

spin up a totally new environment for every build but if you are building local copies they can clash

That's not a typical workflow, but from experience your requirement would be better serviced by custom presets in your CMakeUserPresets.json file. As the name implies, this preset is there mainly for CI purposes.

[GabrielDosReis]

As the name implies, this preset is there mainly for CI purposes.

Nevertheless, the hardcoding of the bindir in CMakePresets.json looks a bit unnecessary when it could be set on the command line invoking the ci-* pipeline -- elsewhere, we explicitly specify the build directory.

[friendlyanon]

Seems like a bit of an invented problem to me.

BUILDING.md is intended as a quick guide for a user to build a project, but the presets only serve developer and CI needs. This is the correct thing to do, since you cannot (and thus must not) anticipate every setup out there.

Considering the above, I don't understand what a preset is doing in BUILDING.md to begin with. That preset is also just a copy of ci-windows and there isn't much of an explanation why. "Added preset value for building the testing executables", yet the dev-mode preset already achieves that by enabling the developer mode code paths that include(CTest), which defaults BUILD_TESTING to truthy.

[GabrielDosReis]

but the presets only serve developer and CI needs.

That is what we are discussing here. As a developer, my build directory is entirely outside the source tree (for other reasons). That isn't an invented problem - it is common practice in certain settings.

Considering the above, I don't understand what a preset is doing in BUILDING.md to begin with.

I suspect part of this is that some IDEs likes to encourage presets and take advantage of them. Most of my development work on this repo happens on the command line and VS Code so I am not personally bothered by it. However, that is not a universal setup for folks wanting to contribute and I see no fundamental reason to actively make the presets not usable by them.

That preset is also just a copy of ci-windows and there isn't much of an explanation why.

That is a fair criticism. I can't remember why that was done that way initially.

[friendlyanon]

I see. Even still, my own user presets never deviate from the CI ones in just the binary directory path and I often ignore majority of the building block presets when putting my own user preset together.

[davidhunter22]

One reason I prefer using the presets rather than my own is that they define various compile flags, for instance /Zc:preprocessor on MSVC.
If I use a my own stuff my code may build because I use different flags and then fail on the CI build.

[friendlyanon]

Using presets and a different binary directory are not mutually exclusive. I don't know where this misunderstanding came from. The developer documentation also has an example of setting up user presets with your exact scenario https://github.com/microsoft/ifc/blob/main/HACKING.md#presets