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@xxxxxxxxx> 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
