Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
vcpkg.targets should not automatically attempt to link in every single installed library #306
Currently the vcpkg targets file adds
I just spent the last 2 hours cleaning, building, and rebuilding my CMake configuration, target configs and every last one of my tests because of this :(
Adding the vcpkg directories as search directories is fine; adding every library as an input is not.
added a commit
Nov 26, 2016
First, thank you for bringing up the issue with gtest/gmock; I'm sincerely sorry that it cause you so much pain :(. I believe I've fixed the issue on the
What we are trying to implement using
In the case of per-project package managers, this is an essential feature (NuGet, conan, hunter, etc). In the general case of system package managers, this is completely impossible because decisions are (rarely, but often enough) made during the link process like the issue you hit above: Do I implement main or does gmock implement main for me? Do I use version X or version Y? In the case of Vcpkg, due to the specific constraints we have placed on the system, the vast majority of libraries (99%+) will not have decisions to be made at link time. All decisions about the binary (version/compiler/flags/etc) are made via the portfile.cmake and the triplet file. We know the exact
However, there are some pitfalls just like the one you hit above! For some reason, it seems gmock and gtest didn't factor their symbols into uniquely-owning DLLs and instead
To address this issue, I have added a subdirectory of
Additionally, you're totally right that some developers will want to use the link line as a "final defense" against pulling in additional dependencies. To this end, I've also added an MSBuild property called
Above, I mentioned MSBuild; what about CMake? CMake is designed from the ground up to allow your project to be as platform agnostic as possible, so this functionality should be entirely opt-in for CMake projects, if available, to mimic other platforms as closely as possible. We previously had a bug which would enable the autolinking for MSBuild projects generated via our CMake toolchain -- I have also fixed that bug in 32157f8 so if you're currently using CMake for your projects that should fix the issue for you.
Finally, thanks for also bringing up the issue that we're adding the include and lib paths ahead of the user-specified paths! I believe I've fixed that issue in the above commit as well.
Well, I got a chance to test it sooner than I thought I would. Everything builds (and works) as I would expect, although I end up with this as the "Additional Library Directories" for the Visual Studio projects generated by CMake:
Although it's mostly the ones with