Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?

From: Philip Oakley <philipoakley@iee.email>
Date: May 30, 2021, 15:24 UTC
Message-ID: <e33bd72f-2095-f32d-5f4f-6137f6a12d22@iee.email>
In-Reply-To: <CAKiG+9WwRHz-5JDPe6KL763kVfRP7vX5HgtDMiX-S1Je5+oWfg@mail.gmail.com>

On 30/05/2021 15:29, Sibi Siddharthan wrote:

Show 15 quoted lines

> On Sun, May 30, 2021 at 6:52 PM Matt Rogers <mattr94@gmail.com> wrote:
>
>> I think the best middle of the line solution would be to just provide a manual
>> knob for turning vcpkg support on/off here and offer configurations in
>> CMakePresets.json for both situations.  The only downside here is that I believe
>> a lot of IDE's are aggressive about running the cmake configuration step and may
>> try to install vcpkg even if it is unnecessary.  But automatic
>> generation can generally
>> be turned off by users I guess.
> I agree. I would suggest vcpkg should be used by default for Windows platforms.
> This way IDE's won't complain and command line users can straight up
> disable this behaviour.
>
> Thank You,
> Sibi Siddharthan

I think so as well.

I'd started writing (draft) in reply to Matt

"I'd agree that knowledgable users should be able to control the settings, however I'm against forcing less knowledgable users being required to add extra control option for knobs they don't yet understand, hence the desire to ensure a consistent (though possible old-fashioned/backward-compatible) settings 'that just work' that do not set in stone those choices, which would be the worst of both worlds!

It maybe that in some ways we may have missed the boat as those project based CMakePresets.json presets (setting back to old defaults) could 'annoy' the (potentially) experienced users who are simply using the new defaults. This doesn't affect (*) truly experience users who are setting their desired options directly as they would/should override the presets."

My other consideration is that the build process should generate enough of the right artefacts (e.g. a .sln etc). This is so that other typical tools and extensions e.g. Sourcetrail which expects the .sln, but maybe they'll also cope with Ninja/Cmake builds soon...

I'll have a go, though I'll be off-line for a while from ~Tuesday.

Philip

(*) - affect/effect? https://www.londonschool.com/nordic/blogg/whats-difference-between-affect-and-effect-and-when-should-they-be-used/