From: Philip Oakley <philipoakley@iee.email>
To: Sibi Siddharthan <sibisiddharthan.github@gmail.com>,
Matt Rogers <mattr94@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Danh Doan <congdanhqx@gmail.com>
Subject: Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?
Date: Sun, 30 May 2021 23:26:25 +0100 [thread overview]
Message-ID: <580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email> (raw)
In-Reply-To: <e33bd72f-2095-f32d-5f4f-6137f6a12d22@iee.email>
On 30/05/2021 16:24, Philip Oakley wrote:
> 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,
> 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
next prev parent reply other threads:[~2021-05-30 22:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 15:00 [RFH] CMake: detect if being run via Visual Studio, independent of build generator? Philip Oakley
2021-05-29 15:49 ` Matt Rogers
2021-05-29 16:25 ` Philip Oakley
2021-05-29 18:33 ` Sibi Siddharthan
2021-05-29 20:31 ` Philip Oakley
2021-05-29 22:14 ` Sibi Siddharthan
2021-05-30 0:14 ` Matt Rogers
2021-05-30 10:52 ` Philip Oakley
2021-05-30 13:22 ` Matt Rogers
2021-05-30 14:29 ` Sibi Siddharthan
2021-05-30 15:24 ` Philip Oakley
2021-05-30 22:26 ` Philip Oakley [this message]
2021-05-31 0:01 ` Matt Rogers
2021-05-31 17:12 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email \
--to=philipoakley@iee.email \
--cc=congdanhqx@gmail.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=mattr94@gmail.com \
--cc=sibisiddharthan.github@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).