On 31/05/2021 01:01, Matt Rogers wrote: Thanks for the reply. Just hoping we aren't talking at cross purposes here, filling out details where I can... >>> 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... >>> > Something to keep in mind is that the generator is what decides what artifacts > get produced. However, Visual Studio default install makes that decision for you (any such user), and has changed that default in the last couple of years (from Visual Studio generator to Ninja generator). > As a consumer of the CMakeLists.txt it's on you to tell > CMake what > your tool needs Here (this discussion), there are two different 'tools' being considered. 1) the Git for Windows build instructions for those hoping to build & browse the code (using VS). 2) my hope that I can add Sourcetrail to that browse capability. It's (1) that has broken at some point 'recently'. (Our build detected MSVC as an indicator of being on Visual Studio, etc. There is now no indicator for CMake, of being on Visual Studio, that works across all releases) I'm trying to un-break (1), and hopefully enable (2) while at it. > , i.e. if it needs a compile_commands.json to run clang-tidy or a > .sln file or a ninja.build that would be on the user to generate. I > think that's > acceptable, if there are common tools in use that require a more > complicated cmake > invocation to get that generation, then it might pay to define a preset in our > CMakePresets.json Noting: CMakePresets.json files are supported in Visual Studio 2019 version 16.10 or later. [1] I'm not sure when Ninja became the default generator in Visual Studio (esp. Community Ed). A quick search didn't locate that info. I'm expecting there to be a gap between the Ninja change and the CmakePresets support, that will need documenting/advising for users hoping to browse the GfW code, so they can ensure they have a recent enough version 'out of the box'. > so that users can get those artifacts with a straightforward > invocation like: > > cd contrib/buildsystems > mkdir build > cd build > cmake --preset sourcetrail .. > > which I would still consider pretty "batteries included". I'm targetting the user who will start from Visual Studio defaults and open the git folder, rather than be in a terminal, so perhaps a bit of divergence of approach here. > > I do think however is that there are a few problems you're > encountering in this case: > > 1. Visual Studio build breaks because we don't install vcpkg here when we should True > 2. Visual Studio is no longer creating the .sln files, which some of > your external tools > were relying on. It would/has but it's catch22 -- I had already installed the vcpkg files in the past so that step didn't need to happen. I also, I think maybe had an old VS version (it gets confused here), I tried various things,, during which the (hidden folder) .vs/git.sln file was generated (Yay). >From then on I could use Sourcetrails integration extension, but I wanted to go back and re-verify that a basic user could build, from scratch, GfW as per instructions. So I unistalled Visual Studio and CMake I's also installed, re-installed just 'Microsoft Visual Studio Community 2019 Version 16.9.4' and tried the File->Open->Git directory step, wherein CMakeLists.txt is detected, and run, and fails... sigh. Starts digging holes. > > I think that the solution to 1. would be to add a knob for vcpkg > installation, and either > have that knob "on" by default and/or provide a configuration in a > CMakePresets.json > that Visual Studio (and other IDE's/tools) could use to build. Knobs are difficult.. I'd agree, with the extra point that the instructions need to tell users to inspect their VS version (>=16.10), and either, maybe fiddle with the GfW CMakeLists.txt to switch generators to VS/MSVC (relative to the main Git Cmake), or instruct users to run/rerun the build with additional options (though more potential for finger trouble errors). > > I think the problem with 2. is that CMake is a build file generator > rather than an actual > build system itself, so it needs a user to tell it what kind of files > that their tools expect. True, and it can't ask for user input. > And I don't think there's any way to make it guess what kind of files the > user expects cmake to generate. Depending on the complexity of the > configuration > it may be worth providing a CMakePresets.json file to make it easier to use, but > I guess it would depend on what exactly you need it to do. True. Philip > [1] https://docs.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-160
