{"thread":{"id":"55798","subject":"[RFH] CMake: detect if being run via Visual Studio, independent of build generator?","startedAt":"2021-05-29T15:00:27Z","lastAt":"2021-05-31T17:14:44Z","messageCount":14,"participants":["Philip Oakley","Matt Rogers","Sibi Siddharthan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425883","messageId":"013f42a4-19f4-a935-7068-db3f7ff40446@iee.email","threadId":"55798","inReplyTo":null,"subject":"[RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-29T15:00:21Z","receivedAt":"2021-05-29T15:00:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi,\ncc'ing those who've been involved with the CMake tool recently.\n\nI've been looking at part of the Git-for-Windows (GfW) Visual Studio\nbuild process that uses the CMakeLists.txt approach [A,B], which is\nbased on the git.git version. In part it's now, for an uninformed user,\nbroken, in an awkward way, hence the subject line question.\n\nAn uniformed user is expected to clone git, download Visual Studio, and\nfile-open the /git directory. Visual Studio will then find the\nCMakeLists.txt and create a hidden .sln/.vcproj project ready to build.\n\nIn recent times Visual Studio has added the Ninja build generator, in\naddition to it's historic visual studio generator, and made Ninja the\ndefault (unless specifically configured otherwise e.g. [1]). This change\nof generator breaks the detection of being in Visual Studio (using Win32\nand MSVC flags). We used these flags as a cue to pre-load the vcpkg\nlibraries, but no longer. Also note Visual Studio embeds its own CMake\nversion.\n\n\nOne issue for creating an update is that the CMake file is meant to be\nOS independent, and the Ninja generator is also OS independent, so\nshouldn't be used as the indicator of working with Visual Studio.\nLikewise using the Win32 CMake flag isn't appropriate for those not\nusing Visual Studio. So the issue, as best I see it, is how to decide\nwhen to pre-load the vcpkg libraries needed for the build.\n\nThe CI for the git.git test of CMake preloads it's essential\npre-requites (as an informed user;-) so avoids those Visual Studio\nchanges to it's defaults.\n\nThe ultimate aim is to make it as simple as possible for GfW users to\nbrowse the Git code, without feeling that they have taken the\ndeveloper/contributor commitment step, which appears to scare off some\nusers.\n\nPart of that simple usage is that existing Visual Studio support tools\ncan expect  .sln/.vcproj files to be available to 'just work' out of the\nbox. In particular (for me) Sourcetrail [2,3], with it's easy graphic\nvisualisation and tracing through the code, is one target. Sourcetrail\nisn't quite there yet but..[4]\n\nThis issue is tricky to test as it (pretend to be that inexperienced\nuser) expects a clean VS install and no vcpkg prior install.\n\nI could be totally confused (I am feeling rather dumb on this one), but\nI'd be grateful of any help in clarifying a way out for detecting if the\nconditions are right to pre-load the vcpkg libraries. I've also raised\nan issue at [5]\n\n--\nPhilip\nearlier discussions at\nhttps://github.com/git-for-windows/git/discussions/3176\n\n[A]\nhttps://github.com/git/git/blob/master/contrib/buildsystems/CMakeLists.txt\n[B]\nhttps://github.com/git-for-windows/git/blob/main/contrib/buildsystems/CMakeLists.txt\n[1] https://github.com/microsoft/vscode-cmake-tools/issues/1084\n[2] https://github.com/CoatiSoftware/Sourcetrail\n[3]\nhttps://github.com/git-for-windows/git/wiki/Sourcetrail-code-viewer-and-linkage-to-Visual-Studio,-for-Git\n[4] https://github.com/CoatiSoftware/Sourcetrail/issues/1179\n[5] https://github.com/MicrosoftDocs/cpp-docs/issues/3167\n"},{"id":"425885","messageId":"CAOjrSZtWVEUNEuJFw8WGPAW0YNccN9LWyuHZ28aKecdjd6dp=A@mail.gmail.com","threadId":"55798","inReplyTo":"013f42a4-19f4-a935-7068-db3f7ff40446@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2021-05-29T15:49:30Z","receivedAt":"2021-05-29T15:49:43Z","isPatch":false,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"I have some experience at my job with CMake, but some quick testing\nhas found that adding a check like:\n\nmessage(\"MSVC = ${MSVC} , WIN32 = ${WIN32})\n\nshows that the MSVC is uninitialized and WIN322 is initialized.  so the\nissue is that the MSVC variable isn't being set which is causing\nvcpkg_install.bat to not run, rather than the WIN32 variable.\n\nThe msvc variable is intended to be set whenever the compiler is a Visual C/C++\ncompiler [1].  And it seems like visual studio should be setting that itself\neither via a toolchain or some other mechanism.  As you noted the\nNinja generator\nis os-agnostic and doesn't imply a compiler unlike the Visual Studio family of\ngenerators.\n\nrunning CMake with -DMSVC=1 should resolve the issue (Assuming you're\nactually using\nan MSVC based compiler).  If the CMake is intended to support non-MSVC\ncompilers like\nclang, etc. and vcpkg is required to do that build then the MSVC\nportion of the check\nshould be removed, otherwise I am not sure if it's a Visual Studio\nissue for not correctly\nconfiguring with MSVC=1 when using an MSVC-based compiler or on the\nCMakeList.txt file\nfor not correctly specifying when vcpk_install.bat needs to be\ninstalled.  I don't really\nknow what vcpkg does in the build to be sure though.\n\n1: https://cmake.org/cmake/help/latest/variable/MSVC.html\n"},{"id":"425886","messageId":"7aadc622-ad4f-1d7e-a956-57ab74f18096@iee.email","threadId":"55798","inReplyTo":"CAOjrSZtWVEUNEuJFw8WGPAW0YNccN9LWyuHZ28aKecdjd6dp=A@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-29T16:25:11Z","receivedAt":"2021-05-29T16:25:35Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 29/05/2021 16:49, Matt Rogers wrote:\n> I have some experience at my job with CMake, but some quick testing\n> has found that adding a check like:\n>\n> message(\"MSVC = ${MSVC} , WIN32 = ${WIN32})\n>\n> shows that the MSVC is uninitialized and WIN322 is initialized.  so the\n> issue is that the MSVC variable isn't being set which is causing\n> vcpkg_install.bat to not run, rather than the WIN32 variable.\n\nThanks for confirming what I'm seeing. It's good to have.\n>\n> The msvc variable is intended to be set whenever the compiler is a Visual C/C++\n> compiler [1].  And it seems like visual studio should be setting that itself\n> either via a toolchain or some other mechanism.\n\nThat is what VS used to do (as best I understand it)\n\n>   As you noted the\n> Ninja generator\n> is os-agnostic and doesn't imply a compiler unlike the Visual Studio family of\n> generators.\n\nWhich (Ninja) is the new VS default - classic latest and greatest\nbreaking backward compatible ;-)\n\n>\n> running CMake with -DMSVC=1 should resolve the issue (Assuming you're\n> actually using\n> an MSVC based compiler).\n\nThe CMake is being run automatically by VS when it opens the folder,\nfails to find the .sln, so searches for the CMakeList.txt file, so can't\nadd in the flag (with the current approach)..\n\n>   If the CMake is intended to support non-MSVC\n> compilers like\n> clang, etc. and vcpkg is required to do that build then the MSVC\n> portion of the check\n> should be removed, \nId agree about removal, but I'm not sure what should be in it's place to\nensure we have localised to being built within VS..\n> otherwise I am not sure if it's a Visual Studio\n> issue for not correctly\n> configuring with MSVC=1 when using an MSVC-based compiler or on the\n> CMakeList.txt file\n> for not correctly specifying when vcpk_install.bat needs to be\n> installed.  \nIt's sort of both. It's that change of default generator that's tripped\nup everything.\n\nI think I may need to look into Ninja to see if there is anything there\nthat will help.\n\nUltimately the goal is to get the .sln to support other [Sourcetrail]\ntools (which needs an actual build)\n\n> I don't really\n> know what vcpkg does in the build to be sure though.\nBasically, the .bat file gets all our library dependencies in a nice\npackaged manner  (~Visual C Packager - vcpkg)\n>\n> 1: https://cmake.org/cmake/help/latest/variable/MSVC.html\nPhilip\n"},{"id":"425889","messageId":"CAKiG+9U70wXm7MtTLMUpPC_aHMp58bTtJBbP=NgoAcQQmCPSuQ@mail.gmail.com","threadId":"55798","inReplyTo":"7aadc622-ad4f-1d7e-a956-57ab74f18096@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Sibi Siddharthan","fromEmail":"sibisiddharthan.github@gmail.com","sentAt":"2021-05-29T18:33:15Z","receivedAt":"2021-05-29T18:33:32Z","isPatch":false,"sender":{"key":"sibisiddharthan.github@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44207430?v=4"},"body":"On Sat, May 29, 2021 at 9:55 PM Philip Oakley <philipoakley@iee.email> wrote:\n>\n> On 29/05/2021 16:49, Matt Rogers wrote:\n> > I have some experience at my job with CMake, but some quick testing\n> > has found that adding a check like:\n> >\n> > message(\"MSVC = ${MSVC} , WIN32 = ${WIN32})\n> >\n> > shows that the MSVC is uninitialized and WIN322 is initialized.  so the\n> > issue is that the MSVC variable isn't being set which is causing\n> > vcpkg_install.bat to not run, rather than the WIN32 variable.\n>\n> Thanks for confirming what I'm seeing. It's good to have.\n> >\n> > The msvc variable is intended to be set whenever the compiler is a Visual C/C++\n> > compiler [1].  And it seems like visual studio should be setting that itself\n> > either via a toolchain or some other mechanism.\n>\n\nCMake sets this variable.\nPlease see {CMAKE_INSTALLATION}/share/cmake-<version>/modules/Platform/Windows-MSVC.cmake.\nThis happens after CMake is required to find a compiler.\nThis happens in line:93 where we enable the C language.\n\nTo fix this I would suggest to change line:53\n\n-  if(MSVC AND NOT EXISTS ${VCPKG_DIR})\n+ if(CMAKE_GENERATOR MATCHES \"Visual Studio\" AND NOT EXISTS ${VCPKG_DIR})\n\nand\nadd CMakeSettings.json to force Visual Studio to use MSBuild.\nPlease see https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160\n\n\n\nThank You,\nSibi Siddharthan\n"},{"id":"425890","messageId":"7ac2c0f4-e8ed-5676-1f81-3446e33def9c@iee.email","threadId":"55798","inReplyTo":"CAKiG+9U70wXm7MtTLMUpPC_aHMp58bTtJBbP=NgoAcQQmCPSuQ@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-29T20:31:29Z","receivedAt":"2021-05-29T20:31:33Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 29/05/2021 19:33, Sibi Siddharthan wrote:\n> On Sat, May 29, 2021 at 9:55 PM Philip Oakley <philipoakley@iee.email> wrote:\n>> On 29/05/2021 16:49, Matt Rogers wrote:\n>>> I have some experience at my job with CMake, but some quick testing\n>>> has found that adding a check like:\n>>>\n>>> message(\"MSVC = ${MSVC} , WIN32 = ${WIN32})\n>>>\n>>> shows that the MSVC is uninitialized and WIN322 is initialized.  so the\n>>> issue is that the MSVC variable isn't being set which is causing\n>>> vcpkg_install.bat to not run, rather than the WIN32 variable.\n>> Thanks for confirming what I'm seeing. It's good to have.\n>>> The msvc variable is intended to be set whenever the compiler is a Visual C/C++\n>>> compiler [1].  And it seems like visual studio should be setting that itself\n>>> either via a toolchain or some other mechanism.\n> CMake sets this variable.\n> Please see {CMAKE_INSTALLATION}/share/cmake-<version>/modules/Platform/Windows-MSVC.cmake.\n> This happens after CMake is required to find a compiler.\n> This happens in line:93 where we enable the C language.\n\nAhh, so it (MSVC) would be unset at that point no matter what at that\nearly point in the code, yes?\n\n>\n> To fix this I would suggest to change line:53\n>\n> -  if(MSVC AND NOT EXISTS ${VCPKG_DIR})\n> + if(CMAKE_GENERATOR MATCHES \"Visual Studio\" AND NOT EXISTS ${VCPKG_DIR})\n\nI'd seen this one recommended on a few StackOverflow answers but it no\nlonger works (for a new install of Visual Studio) because\nCMAKE_GENERATOR is now set to \"Ninja\" as default (sigh).\n\nSimply dropping the MSVC test may be one option - we are already guarded\nby the earlier WIN32 test so were aren't on another OS, though I expect\nthere could be some who want to not use VS, and already have options..\n> and\n\n> add CMakeSettings.json to force Visual Studio to use MSBuild.\n\nI was trying to avoid requiring VS users do any extra set up steps. Too\nmany steps often puts off new users, and forcing a change could be\nannoying for established users - hence the caution.\n\n> Please see https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160\n\nI'll have a look.\n\nThanks.\n"},{"id":"425892","messageId":"CAKiG+9UeT70S3_jNXUbx2KCM6UDUxPKMizFX_fUiioDo-zmp+Q@mail.gmail.com","threadId":"55798","inReplyTo":"7ac2c0f4-e8ed-5676-1f81-3446e33def9c@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Sibi Siddharthan","fromEmail":"sibisiddharthan.github@gmail.com","sentAt":"2021-05-29T22:14:01Z","receivedAt":"2021-05-29T22:14:15Z","isPatch":false,"sender":{"key":"sibisiddharthan.github@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44207430?v=4"},"body":"> Ahh, so it (MSVC) would be unset at that point no matter what at that\n> early point in the code, yes?\n>\n\nyes\n\n> >\n> > To fix this I would suggest to change line:53\n> >\n> > -  if(MSVC AND NOT EXISTS ${VCPKG_DIR})\n> > + if(CMAKE_GENERATOR MATCHES \"Visual Studio\" AND NOT EXISTS ${VCPKG_DIR})\n>\n> I'd seen this one recommended on a few StackOverflow answers but it no\n> longer works (for a new install of Visual Studio) because\n> CMAKE_GENERATOR is now set to \"Ninja\" as default (sigh).\n>\n> Simply dropping the MSVC test may be one option - we are already guarded\n> by the earlier WIN32 test so were aren't on another OS, though I expect\n> there could be some who want to not use VS, and already have options..\n\nI am one of them, I use clang and MSVC with Ninja.\n\n> > and\n>\n> > add CMakeSettings.json to force Visual Studio to use MSBuild.\n>\n> I was trying to avoid requiring VS users do any extra set up steps. Too\n> many steps often puts off new users, and forcing a change could be\n> annoying for established users - hence the caution.\n>\n\nYeah, I agree.\n\nRight now, I seriously think that we need to revert\n958a5f5dfe4dda4fd59af30c1d58abe43ff19d6e.\nThis patch also hurts command line users like me.\n\nA more complete solution would involve adding an explicit option to use vcpkg.\nThis can cater to people who prefer using vcpkg and to people who\nprefer using their\nown packages (like me).\nBut this means that you have to generate the solution file using the command\nline. Some people might be put off due to this extra  'single' step.\n\nI am afraid this is a situation where you cannot make everyone happy.\n\nThank You,\nSibi Siddharthan\n\n\n\n.\n"},{"id":"425893","messageId":"CAOjrSZtRH-sqh8RJm3W00dUWTbT-xcpzDWCQFt=3CNaVnOyVWQ@mail.gmail.com","threadId":"55798","inReplyTo":"CAKiG+9UeT70S3_jNXUbx2KCM6UDUxPKMizFX_fUiioDo-zmp+Q@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2021-05-30T00:14:28Z","receivedAt":"2021-05-30T00:14:42Z","isPatch":false,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"(resending because client reconfigured to not use plaintext)\n\nReading through the documentation, Visual Studio seems to support\nCmakePresets.json [1] for handling configuration of cmake options.  It\nmight be worth it to keep the defaults as is. But provide a variable\nfor forcing vcpkg and a CMakePresets.json for Visual Studio\n(and other such tools) to use.\n\nThis is nice since Visual Studio users wouldn't need to rely on the\nslower Visual Studio * generators to run their builds, while leaving\nnon Visual Studio users still able to easily run builds.  So maybe there's\na way for everyone to be happy?\n\n1: https://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/\n\n-- \nMatthew Rogers\n"},{"id":"425911","messageId":"953d685c-3c89-7377-ed49-b79fb4e0acb5@iee.email","threadId":"55798","inReplyTo":"CAOjrSZtRH-sqh8RJm3W00dUWTbT-xcpzDWCQFt=3CNaVnOyVWQ@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-30T10:52:47Z","receivedAt":"2021-05-30T10:52:50Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"quick thoughts..\nOn 30/05/2021 01:14, Matt Rogers wrote:\n> (resending because client reconfigured to not use plaintext)\n;-)\n>\n> Reading through the documentation, Visual Studio seems to support\n> CmakePresets.json [1]\nIs that stored with the project, or with the VS installation (still to\nread [1] beyond a v quick scan..)\n>  for handling configuration of cmake options.  It\n> might be worth it to keep the defaults as is.\n\nGiven that it's just changed, do you mean ' keep it as new - Ninja' or\n'keep it as old - VS generator'..\n\n>  But provide a variable\n> for forcing vcpkg and a CMakePresets.json for Visual Studio\n> (and other such tools) to use.\n>\n> This is nice since Visual Studio users wouldn't need to rely on the\n> slower Visual Studio * generators to run their builds, \n[implies, keep as Ninja, I think ?]\n> while leaving\n> non Visual Studio users still able to easily run builds.  So maybe there's\n> a way for everyone to be happy?\nI'm hoping to ensure the project builds 'straight out of the tin' [mixed\nmetaphor 2,3], for those who are cross disciplinary (such as myself;-)\n\nI'll have a good look at [1], thanks.\n\nPhilip\n\n>\n> 1: https://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/\n>\n[2] https://en.wikipedia.org/wiki/Out_of_the_box_(feature)\n[3] https://www.ronseal.com/the-ronseal-phrase/ (UK)\n"},{"id":"425921","messageId":"CAOjrSZuzgBs8camWdUjEU+JOjRYwv3MVjRgnyW50pchq6rpYsQ@mail.gmail.com","threadId":"55798","inReplyTo":"953d685c-3c89-7377-ed49-b79fb4e0acb5@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2021-05-30T13:22:39Z","receivedAt":"2021-05-30T13:22:51Z","isPatch":false,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"On Sun, May 30, 2021 at 6:52 AM Philip Oakley <philipoakley@iee.email> wrote:\n>\n> quick thoughts..\n> On 30/05/2021 01:14, Matt Rogers wrote:\n> > (resending because client reconfigured to not use plaintext)\n> ;-)\n> >\n> > Reading through the documentation, Visual Studio seems to support\n> > CmakePresets.json [1]\n> Is that stored with the project, or with the VS installation (still to\n> read [1] beyond a v quick scan..)\n\nThis file would live in our source tree next to our CMakeLists.txt.  It's kind\nof cmakes answer to the problem CMakeSettings.json was trying to solve.\n\n> >  for handling configuration of cmake options.  It\n> > might be worth it to keep the defaults as is.\n>\n> Given that it's just changed, do you mean ' keep it as new - Ninja' or\n> 'keep it as old - VS generator'..\n>\n\nUsers should be free to use arbitrary generators and have them work\nout of the box for normal use cases (here I'm thinking of IDE integrations\nas well as just running builds).  So you should have the option to use\neither Visual Studio with Ninja or with the Visual Studio 2019 generator.\nI personally prefer Ninja, but maybe somebody is stuck using an older version,\nor would prefer to have a .sln file for other reasons.\n\nPersonally, I think that most users not knowing anything would go in\nthinking that arbitrary generators are equally supported with perhaps\na small number of knobs.\n\nBy default Visual Studio 2019 is probably doing an invocation something\nlike:\n\nmkdir out && cd out && cmake -G Ninja ..\n\nWhich would ideally just work automagically.  But if for example you wanted\nto support using vcpkg as a package source, we're pretty much forced to\nprovide a knob here (what if I wanted to use Visual Studio as my IDE but\nnot want to use vcpkg to manage those dependencies for example).\n\nI think the best middle of the line solution would be to just provide a manual\nknob for turning vcpkg support on/off here and offer configurations in\nCMakePresets.json for both situations.  The only downside here is that I believe\na lot of IDE's are aggressive about running the cmake configuration step and may\ntry to install vcpkg even if it is unnecessary.  But automatic\ngeneration can generally\nbe turned off by users I guess.\n\n\n-- \nMatthew Rogers\n"},{"id":"425922","messageId":"CAKiG+9WwRHz-5JDPe6KL763kVfRP7vX5HgtDMiX-S1Je5+oWfg@mail.gmail.com","threadId":"55798","inReplyTo":"CAOjrSZuzgBs8camWdUjEU+JOjRYwv3MVjRgnyW50pchq6rpYsQ@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Sibi Siddharthan","fromEmail":"sibisiddharthan.github@gmail.com","sentAt":"2021-05-30T14:29:26Z","receivedAt":"2021-05-30T14:30:10Z","isPatch":false,"sender":{"key":"sibisiddharthan.github@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44207430?v=4"},"body":"On Sun, May 30, 2021 at 6:52 PM Matt Rogers <mattr94@gmail.com> wrote:\n\n>\n> I think the best middle of the line solution would be to just provide a manual\n> knob for turning vcpkg support on/off here and offer configurations in\n> CMakePresets.json for both situations.  The only downside here is that I believe\n> a lot of IDE's are aggressive about running the cmake configuration step and may\n> try to install vcpkg even if it is unnecessary.  But automatic\n> generation can generally\n> be turned off by users I guess.\n\nI agree. I would suggest vcpkg should be used by default for Windows platforms.\nThis way IDE's won't complain and command line users can straight up\ndisable this behaviour.\n\nThank You,\nSibi Siddharthan\n"},{"id":"425924","messageId":"e33bd72f-2095-f32d-5f4f-6137f6a12d22@iee.email","threadId":"55798","inReplyTo":"CAKiG+9WwRHz-5JDPe6KL763kVfRP7vX5HgtDMiX-S1Je5+oWfg@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-30T15:24:53Z","receivedAt":"2021-05-30T15:24:56Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/05/2021 15:29, Sibi Siddharthan wrote:\n> On Sun, May 30, 2021 at 6:52 PM Matt Rogers <mattr94@gmail.com> wrote:\n>\n>> I think the best middle of the line solution would be to just provide a manual\n>> knob for turning vcpkg support on/off here and offer configurations in\n>> CMakePresets.json for both situations.  The only downside here is that I believe\n>> a lot of IDE's are aggressive about running the cmake configuration step and may\n>> try to install vcpkg even if it is unnecessary.  But automatic\n>> generation can generally\n>> be turned off by users I guess.\n> I agree. I would suggest vcpkg should be used by default for Windows platforms.\n> This way IDE's won't complain and command line users can straight up\n> disable this behaviour.\n>\n> Thank You,\n> Sibi Siddharthan\nI think so as well.\n\nI'd started writing (draft) in reply to Matt\n\n\"I'd agree that knowledgable users should be able to control the\nsettings, however I'm against forcing less knowledgable users being\nrequired to add extra control option for knobs they don't yet\nunderstand, hence the desire to ensure a consistent (though possible\nold-fashioned/backward-compatible) settings 'that just work' that do not\nset in stone those choices, which would be the worst of both worlds!\n\nIt maybe that in some ways we may have missed the boat as those project\nbased CMakePresets.json presets (setting back to old defaults) could\n'annoy' the (potentially) experienced users who are simply using the new\ndefaults. This doesn't affect (*) truly experience users who are setting\ntheir desired options directly as they would/should override the presets.\"\n\nMy other consideration is that the build process should generate enough\nof the right artefacts (e.g. a .sln etc). This is so that other typical\ntools and extensions e.g. Sourcetrail which expects the .sln, but maybe\nthey'll also cope with Ninja/Cmake builds soon...\n\nI'll have a go, though I'll be off-line for a while from ~Tuesday.\n\nPhilip\n\n(*) - affect/effect?\nhttps://www.londonschool.com/nordic/blogg/whats-difference-between-affect-and-effect-and-when-should-they-be-used/\n"},{"id":"425947","messageId":"580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email","threadId":"55798","inReplyTo":"e33bd72f-2095-f32d-5f4f-6137f6a12d22@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-30T22:26:25Z","receivedAt":"2021-05-30T22:26:29Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/05/2021 16:24, Philip Oakley wrote:\n> On 30/05/2021 15:29, Sibi Siddharthan wrote:\n>> On Sun, May 30, 2021 at 6:52 PM Matt Rogers <mattr94@gmail.com> wrote:\n>>\n>>> I think the best middle of the line solution would be to just provide a manual\n>>> knob for turning vcpkg support on/off here and offer configurations in\n>>> CMakePresets.json for both situations.  The only downside here is that I believe\n>>> a lot of IDE's are aggressive about running the cmake configuration step and may\n>>> try to install vcpkg even if it is unnecessary.  But automatic\n>>> generation can generally\n>>> be turned off by users I guess.\n>> I agree. I would suggest vcpkg should be used by default for Windows platforms.\n>> This way IDE's won't complain and command line users can straight up\n>> disable this behaviour.\n>>\n>> Thank You,\n>> Sibi Siddharthan\n> I think so as well.\n>\n> I'd started writing (draft) in reply to Matt\n>\n> \"I'd agree that knowledgable users should be able to control the\n> settings, however I'm against forcing less knowledgable users being\n> required to add extra control option for knobs they don't yet\n> understand, hence the desire to ensure a consistent (though possible\n> old-fashioned/backward-compatible) settings 'that just work' that do not\n> set in stone those choices, which would be the worst of both worlds!\n>\n> It maybe that in some ways we may have missed the boat as those project\n> based CMakePresets.json presets (setting back to old defaults) could\n> 'annoy' the (potentially) experienced users who are simply using the new\n> defaults. This doesn't affect (*) truly experience users who are setting\n> their desired options directly as they would/should override the presets.\"\n>\n> My other consideration is that the build process should generate enough\n> of the right artefacts (e.g. a .sln etc). This is so that other typical\n> tools and extensions e.g. Sourcetrail which expects the .sln, but maybe\n> they'll also cope with Ninja/Cmake builds soon...\n>\n> I'll have a go, \n\nI had a look at the previous link and others (below) but I think there\nis a potential Catch-22 problem as it [see cppblog] also expects the\nuser to do some enabling of the use of presets (If I Read Correctly). My\ninitial use case is 'out of the box' usage;-)\n\nThis suggests I may need to fallback on ensuing we give instructions on\nbypassing the potentially failing parts (e.g. run the vcpkg install one\nself, other steps, ...)\n\nI did find a recent video on the presets which was helpful:\n   An Introduction to CMakePresets.json : the simple example\nhttps://youtu.be/NFbnm1t6Mc4?t=251\n\nIt feels like having both the presets and the fallback instructions may\nbe the way to go to cover the range of use cases,\n\n> though I'll be off-line for a while from ~Tuesday.\n>\n> Philip\n>\n> (*) - affect/effect?\n> https://www.londonschool.com/nordic/blogg/whats-difference-between-affect-and-effect-and-when-should-they-be-used/\n\n\n> Please see\nhttps://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=msvc-160\n\nOther links:\nhttps://cmake.org/cmake/help/latest/manual/cmake-presets.7.html\nhttps://devblogs.microsoft.com/cppblog/cmake-presets-integration-in-visual-studio-and-visual-studio-code/\nhttps://docs.microsoft.com/en-us/cpp/build/cmake-presets-json-reference?view=msvc-160\n"},{"id":"425948","messageId":"CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com","threadId":"55798","inReplyTo":"580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2021-05-31T00:01:09Z","receivedAt":"2021-05-31T00:08:29Z","isPatch":false,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"> > My other consideration is that the build process should generate enough\n> > of the right artefacts (e.g. a .sln etc). This is so that other typical\n> > tools and extensions e.g. Sourcetrail which expects the .sln, but maybe\n> > they'll also cope with Ninja/Cmake builds soon...\n> >\n\nSomething to keep in mind is that the generator is what decides what artifacts\nget produced.  As a consumer of the CMakeLists.txt it's on you to tell\nCMake what\nyour tool needs, i.e. if it needs a compile_commands.json to run clang-tidy or a\n.sln file or a ninja.build that would be on the user to generate.  I\nthink that's\nacceptable, if there are common tools in use that require a more\ncomplicated cmake\ninvocation to get that generation, then it might pay to define a preset in our\nCMakePresets.json so that users can get those artifacts with a straightforward\ninvocation like:\n\ncd contrib/buildsystems\nmkdir build\ncd build\ncmake --preset sourcetrail ..\n\nwhich I would still consider pretty \"batteries included\".\n\nI do think however is that there are a few problems you're\nencountering in this case:\n\n1. Visual Studio build breaks because we don't install vcpkg here when we should\n2. Visual Studio is no longer creating the .sln files, which some of\nyour external tools\nwere relying on.\n\nI think that the solution to 1. would be to add a knob for vcpkg\ninstallation, and either\nhave that knob \"on\" by default and/or provide a configuration in a\nCMakePresets.json\nthat Visual Studio (and other IDE's/tools) could use to build.\n\nI think the problem with 2. is that CMake is a build file generator\nrather than an actual\nbuild system itself, so it needs a user to tell it what kind of files\nthat their tools expect.\nAnd I don't think there's any way to make it guess what kind of files the\nuser expects cmake to generate.  Depending on the complexity of the\nconfiguration\nit may be worth providing a CMakePresets.json file to make it easier to use, but\nI guess it would depend on what exactly you need it to do.\n\n\n\n-- \nMatthew Rogers\n"},{"id":"426020","messageId":"ead4ff2a-dfc0-ef8c-e2c5-477197ddded6@iee.email","threadId":"55798","inReplyTo":"CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com","subject":"Re: [RFH] CMake: detect if being run via Visual Studio, independent of build generator?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-31T17:12:21Z","receivedAt":"2021-05-31T17:14:44Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 31/05/2021 01:01, Matt Rogers wrote:\n\nThanks for the reply. Just hoping we aren't talking at cross purposes\nhere, filling out details where I can...\n>>> My other consideration is that the build process should generate enough\n>>> of the right artefacts (e.g. a .sln etc). This is so that other typical\n>>> tools and extensions e.g. Sourcetrail which expects the .sln, but maybe\n>>> they'll also cope with Ninja/Cmake builds soon...\n>>>\n> Something to keep in mind is that the generator is what decides what artifacts\n> get produced.  \n\nHowever, Visual Studio default install makes that decision for you (any\nsuch user), and has changed that default in the last couple of years\n(from Visual Studio generator to Ninja generator).\n\n> As a consumer of the CMakeLists.txt it's on you to tell\n> CMake what\n> your tool needs\n\nHere (this discussion), there are two different 'tools' being considered.\n1) the Git for Windows build instructions for those hoping to build &\nbrowse the code (using VS).\n2) my hope that I can add Sourcetrail to that browse capability.\n\nIt's (1) that has broken at some point 'recently'.\n(Our build detected MSVC as an indicator of being on Visual Studio, etc.\nThere is now no indicator for CMake, of being on Visual Studio, that\nworks across all releases)\n\nI'm trying to un-break (1), and hopefully enable (2) while at it.\n\n> , i.e. if it needs a compile_commands.json to run clang-tidy or a\n> .sln file or a ninja.build that would be on the user to generate.  I\n> think that's\n> acceptable, if there are common tools in use that require a more\n> complicated cmake\n> invocation to get that generation, then it might pay to define a preset in our\n> CMakePresets.json \n\nNoting: CMakePresets.json files are supported in Visual Studio 2019\nversion 16.10 or later. [1]\n\nI'm not sure when Ninja became the default generator in Visual Studio\n(esp. Community Ed).\nA quick search didn't locate that info. I'm expecting there to be a gap\nbetween the Ninja change and the CmakePresets support, that will need\ndocumenting/advising for users hoping to browse the GfW code, so they\ncan ensure they have a recent enough version 'out of the box'.\n\n> so that users can get those artifacts with a straightforward\n> invocation like:\n>\n> cd contrib/buildsystems\n> mkdir build\n> cd build\n> cmake --preset sourcetrail ..\n>\n> which I would still consider pretty \"batteries included\".\n\nI'm targetting the user who will start from Visual Studio defaults and\nopen the git folder, rather than be in a terminal, so perhaps a bit of\ndivergence of approach here.\n\n>\n> I do think however is that there are a few problems you're\n> encountering in this case:\n>\n> 1. Visual Studio build breaks because we don't install vcpkg here when we should\n\nTrue\n\n> 2. Visual Studio is no longer creating the .sln files, which some of\n> your external tools\n> were relying on.\n\nIt would/has but it's catch22 -- I had already installed the vcpkg files\nin the past so that step didn't need to happen. I also, I think maybe\nhad an old VS version (it gets confused here), I tried various things,,\nduring which the (hidden folder) .vs/git.sln file was generated (Yay).\n\nFrom then on I could use Sourcetrails integration extension, but I\nwanted to go back and re-verify that a basic user could build, from\nscratch, GfW as per instructions. So I unistalled Visual Studio and\nCMake I's also installed, re-installed just 'Microsoft Visual Studio\nCommunity 2019 Version 16.9.4' and tried the File->Open->Git directory\nstep, wherein CMakeLists.txt is detected, and run, and fails... sigh.\nStarts digging holes.\n\n>\n> I think that the solution to 1. would be to add a knob for vcpkg\n> installation, and either\n> have that knob \"on\" by default and/or provide a configuration in a\n> CMakePresets.json\n> that Visual Studio (and other IDE's/tools) could use to build.\n\nKnobs are difficult..\n\nI'd agree, with the extra point that the instructions need to tell users\nto inspect their VS version (>=16.10), and either, maybe fiddle with the\nGfW CMakeLists.txt to switch generators to VS/MSVC (relative to the main\nGit Cmake), or instruct users to run/rerun the build with additional\noptions (though more potential for finger trouble errors).\n\n>\n> I think the problem with 2. is that CMake is a build file generator\n> rather than an actual\n> build system itself, so it needs a user to tell it what kind of files\n> that their tools expect.\n\nTrue, and it can't ask for user input.\n\n> And I don't think there's any way to make it guess what kind of files the\n> user expects cmake to generate.  Depending on the complexity of the\n> configuration\n> it may be worth providing a CMakePresets.json file to make it easier to use, but\n> I guess it would depend on what exactly you need it to do.\n\nTrue.\nPhilip\n>\n[1]\nhttps://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160\n"}]}