Vcpkg: Consider generating CMake config scripts for packages that don't natively provide them

[ras0219-msft]

Relevant to several ports which required rewriting their buildsystems from scratch in CMake (#603).

Because Vcpkg has opinions about how packages should be laid out and linked, we have all the information needed to generate general-purpose CMake configure scripts for every library we package (even those that don't use CMake!). This would greatly simplify the job of maintainers who need to rewrite library buildsystems in CMake to better support our configuration options (UWP, static linking the CRT, etc) because they would be able to rely on find_package() to do the heavy lifting.

Now, it is certainly not our intention to permanently fork libraries, so if a library _did_ decide to start supplying its own native CMake configure scripts, we would have to make (breaking!) changes to switch.

[marcojez]

I second that. In my own package manager, that I've been developing for my company as an internal project, I do exactly that. Furthermore, I leverage the CMake versioning system to be able to provide several versions of the same library at the same time. This often requires the port maintainer to patch existing CMake scripts in order to include the required actions for creating config and version files, as more often than not the original CMake scripts fall into old-style CMake coding (based on the assumption that some Find* scripts will be present on the user machine instead of proper config scripts). But that's a one-time effort that greatly pays off downstream, and - as the OP writes - the package manager has a lot of information that can be leveraged to produce or help producing config files automatically (I do that at several levels in my package manager).

Also, I'd stress on the importance of creating INTERFACE targets for header-only libraries (such as glm), so that dependencies can still be checked.

In my package manager, there is no one common include directory for installed packages: they all live in their own directory (otherwise header files from different versions of the same library would clash). This implies that properly-formed CMake files are a strict requirement, and features like config/version files, INTERFACEtargets, include directories specified via target_include_directories() must always be present (either in the original CMake files or in port-specific patches). As I said before, this requires an effort from the port maintainer, but the package user then is presented with an uniform and consistent interface for finding and using libraries, even header-only ones.

[OlafvdSpek]

we would have to make (breaking!) changes to switch.

What would break and why?
What would / should a Hello World library cmake file look like?
IMO it should be cross-platform and not be tied to vcpkg.

[ras0219-msft]

@OlafvdSpek Definitely! We want to integrate with CMake in a respectful, native way which does _not_ encourage vcpkg-specific behavior in your project (like requiring a include(vcpkg_libraries)). The official CMake way to include prebuilt downstream projects is via a simple find_package(X), so that's what we want projects to use.

The problem is that there are several choices that can be made when adding find_package() support, such as the casing of the package name and the exact spelling and arrangement of the libraries. Many libraries opt for a flat name, so you can do target_link_libraries(hello sqlite3), but others choose (in line with the official CMake guidance) to use namespaces (target_link_libraries(hello Sqlite3::sqlite)).

If the upstream package decides to add official, native CMake support, it's very possible they will choose a naming scheme that conflicts with our generated scheme. We want to support cross-platform projects, so we should switch to the upstream scheme -- but that will cause a break for current Vcpkg users. Providing both _may_ be possible, but we'd really prefer to not to do that in the longer term.

@marcojez That's awesome to hear! I'd definitely appreciate your expertise if we go down this path 👍. For a few reasons detailed in many other issues (primarily consistency as the deps graph grows complex), we explicitly provide exactly one version of each library, so our task may be even easier than what you've already accomplished.

As a side conversation: are you only targeting Windows with that system or is it Linux/osx hosted? I'd love to have a chat about it over mail to make sure we haven't missed some really important features in Vcpkg([email protected])!

[OlafvdSpek]

Ideally #include <zlib.h> would be enough and you'd not have to worry about anything else..

IMO find_package(), pkg-config and friends make build scripts more complex and more fragile then they need to be, ultimately making the sum of everything less flexible.

[MikeGitb]

I don't see a problem with generating config files with target names that might become outdated. First of all, everyone can decide on his own if he wants to use them or not. Second, such a break can easily be fixed. Third, even after a library starts providing native cmake support, the vcpkg version could be kept for some time after as an alias - preferably emitting a warning.

[MikeGitb]

At the very least, it should be possible to querey vcpkg on how to use a particular port from cmake: whether to use find_package or find_library/find_path and what package / header name to look for.

[BillyONeal]

I think we already do this for ports where possible, so this decision is "resolved" in favor of "yes, we're doing that".