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

From: Matt Rogers <mattr94@gmail.com>
To: Philip Oakley <philipoakley@iee.email>
Cc: Sibi Siddharthan <sibisiddharthan.github@gmail.com>,
	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 20:01:09 -0400	[thread overview]
Message-ID: <CAOjrSZusMSvs7AS-ZDsV8aQUgsF2ZA754vSDjgFKMRgi_oZAWw@mail.gmail.com> (raw)
In-Reply-To: <580d858d-dcd3-9d62-ec97-2daa9d9e0f45@iee.email>

> > 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.  As a consumer of the CMakeLists.txt it's on you to tell
CMake what
your tool needs, 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 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 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
2. Visual Studio is no longer creating the .sln files, which some of
your external tools
were relying on.

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.

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

-- 
Matthew Rogers