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

From: Philip Oakley <philipoakley@iee.email>
Date: May 30, 2021, 22:26 UTC
Message-ID: <580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email>
In-Reply-To: <e33bd72f-2095-f32d-5f4f-6137f6a12d22@iee.email>

On 30/05/2021 16:24, Philip Oakley wrote:

Show 39 quoted lines

> On 30/05/2021 15:29, Sibi Siddharthan wrote:
>> 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,

I had a look at the previous link and others (below) but I think there is a potential Catch-22 problem as it [see cppblog] also expects the user to do some enabling of the use of presets (If I Read Correctly). My initial use case is 'out of the box' usage;-)

This suggests I may need to fallback on ensuing we give instructions on bypassing the potentially failing parts (e.g. run the vcpkg install one self, other steps, ...)

I did find a recent video on the presets which was helpful:
   An Introduction to CMakePresets.json : the simple example
https://youtu.be/NFbnm1t6Mc4?t=251

It feels like having both the presets and the fallback instructions may be the way to go to cover the range of use cases,

Show 6 quoted lines

> 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/

> Please see

https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160

Other links: https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html https://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/ https://docs.microsoft.com/en-us/cpp/build/cmake-presets-json-reference?view=msvc-160