vcpkg module

[grisumbras]

Proposed changes

Adds a module for vcpkg support. The module provides target /vcpkg//prefix for manual searching for vcpkg-installed libraries. FIle build/ac.jam also changed to take advantage of vcpkg if it was configured. This will allow existing toolset modules for libraries to gain vcpkg support automatically.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• I searched the discussions
• I searched the closed and open issues
• I read the contribution guidelines
• I added myself to the copyright attributions for significant changes
• I checked that tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• I added necessary documentation (if appropriate)

Further comments

I haven't added any tests. Do I need to in this case?

[grafikrobot]

Why do it this way instead of writing an integration that uses the existing package manager interface? The conan integration, and custom lib modules, standardize on the /<package>//<target> declarations. This is entirely counter to that. Which makes it impossible for people to move between methods of obtaining libraries without also making changes to their jamfiles.

Please change to support the /<package>//<target> organization.

[grisumbras]

I see no way to do it on b2 side. vcpkg doesn't have the concept of generator. It has specific build system "glue" for CMake and MSBuild. For CMake it hijacks find_package to inject its search paths, but still relies on core find_package functionality.

[grisumbras]

BTW, to be clear the point of this module is to give a hint to the build system where to search for libraries. This PR grants existing library toolset modules (e.g. zlib, openssl) to search in vcpkg installation trees.

I have a separate WIP module that would allow on-the-fly creation of such toolset modules. And that would work along the lines of /package//library convention.

[grafikrobot]

I see no way to do it on b2 side. vcpkg doesn't have the concept of generator. It has specific build system "glue" for CMake and MSBuild. For CMake it hijacks find_package to inject its search paths, but still relies on core find_package functionality.

Here's a rough draft of how to do it:

• Have users create a vcpkginfo.jam file in their project where users do the using vcpkg ... ;.
• That declares a rule vcpkg-lib ( ... ) (would need to be imported into the caller module) that when invoked declares the needed <package>//<target> as needed.
• Ideally the vcpkg-lib rule would do host independent searches so that the vcpkginfo.jam files can be checked into source control.
• Change the b2 package manager support to include vcpkginfo.jam automatically.

The result is that users only need to create the vcpkginfo.jam with what they need and nothing else changes and works automatically.

[grisumbras]

Here's a rough draft of how to do it:

My approach (with the aforementioned WIP module) will have pretty much the same result, but also

1. Way less configuration by users will usually be required (potentially, just using vcpkg ; in user-config.jam).
2. Grants vcpkg support to existing modules.

[grafikrobot]

BTW, to be clear the point of this module is to give a hint to the build system where to search for libraries. This PR grants existing library toolset modules (e.g. zlib, openssl) to search in vcpkg installation trees.

Ideally I would prefer to deprecate those built-in modules in favor of package manager methods. Hence...

I have a separate WIP module that would allow on-the-fly creation of such toolset modules. And that would work along the lines of /package//library convention.

I would rather just wait for that work :-)

[vinniefalco]

Having this feature, however implemented, would still be valuable

[pdimov]

• Have users create a vcpkginfo.jam file in their project

But most users don't have a project. They just want to build Boost and have zlib be found.

[grisumbras]

This PR has been essentially superceded by #296. I originally intended them to be separate, but in the end decided to put all of this PR's functionality into 296.