Vcpkg Download Source !EXCLUSIVE!
Madison Spiers
I'm trying to use external libraries (specifically opencv) with C++ but I'm having some trouble. It seems like using vcpkg is the easiest way to go about this. So far I've followed these tutorials: =b7SdgK7Y510 and =iZeK3Ie5Fz0 but I keep getting these errors when I try to include a file:
The quick fix provided by vscode says to install opencv through vcpkg but I've already done that. I've linked vcpkg according to the tutorials and included the path to the cmake toolchain file in my settings.json file.
Searching around on github for a bit can sometimes turn up existing efforts/info and people who may know more. In this case, I stumbled into Add shell.nix for building on NixOS by poelzi Pull Request #15906 microsoft/vcpkg GitHub
I actually found a proper way to make vcpkg behave. I never found time to actually implement it. Basically, the vcpkg toolchain just calls the vcpkg executable. You can replace the executable with a wrapper scripts that sets where to download, install and unpack libraires with command line options.
Lots of people download binary distributions of curl and libcurl. This document does not describe how to install curl or libcurl using such a binary package. This document describes how to compile, build and install curl and libcurl from source code.
Almost identical to the Unix installation. Run the configure script in the curl source tree root with sh configure. Make sure you have the sh executable in /bin/ or you will see the configure fail toward the end.
Spack is a package management tool designed to support multiple versions andconfigurations of software on a wide variety of platforms and environments.It was designed for large supercomputing centers. Spack builds packages fromsources, and allows tweaking their configurations.
More than half a year ago I was trying out Conan package manager for resolving dependencies in our C++ project. The research went well, but we never actually proceeded with switching to Conan for the whole project. And then a couple of weeks ago I started looking into vcpkg.
I think, this is because we chose a wrong approach to it. At the first glance it seemed that integrating Conan as a part of our build system would be too disruptive, so we decided to just pack pre-built artifacts from the install destination with export-pkg -pf. So we were not making source packages and were not implementing the build() method in recipes.
It will in turn call ./scripts/bootstrap.sh script and download the second component - vcpkg CLI tool binary from its repository. In my case it was 2022-09-20 version. It also does some other things, which you can look up in the script file. I would prefer to do all these things myself than letting a script execute a bazillion commands in my system.
In order for vcpkg_cmake_config_fixup() function to work it needs to know where the project installs its CMake configs to. If those are installed into an unusual place (they usually are), then it will fail with an error like this:
To fix that you need to go to /path/to/programs/vcpkg/packages/some-library_x64-osx and find where exactly this project installs its CMake files. For example, if they are in cmake/SomeLibrary, then your vcpkg_cmake_config_fixup() should have the following arguments:
I learned about triplets when I noticed that dependencies in one of my Windows projects were built as DLLs (SHARED libraries), even though I did not set -DBUILD_SHARED_LIBS=1. And it turned out that on Windows by default vcpkg uses x64-windows.cmake triplet, which contents are:
But that project also depends on PDFium, which in turn depends on JPEG/jpeg-turbo too, and in our PDFium port we resolve this the same way via vcpkg (having disabled building those from vendored sources). But the problem now is how to specify which JPEG library should PDFium port use (meaning that it is controlled via PDFium port features)?
As you saw in portfile.cmake, one can use helper packages, which are not libraries for development but CMake modules for extending portfiles functionality. The vcpkg-cmake and vcpkg-cmake-config packages are examples of such helpers.
If the helper is supposed to provide CMake function(s) which could be used in portfiles, then it must contain vcpkg-port-config.cmake - these files get automatically imported/included by vcpkg. The contents of that file should be something like:
The actual port that would be using this helper will be then able to copy the common files into its source directory using that CURRENT_HOST_INSTALLED_DIR variable, as it will always point to the host dependencies path:
Unrelated to that, you might have noticed an ololo message being printed out during the installation of dearimgui port (version 1.88.0). That message came from decovar-vcpkg-cmake helper port, which dearimgui port depends on and calls decovar_vcpkg_cmake_ololo() function from.
$ rm -r ./*; rm .ninja*; ls -lah$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX="../install" \ -DUSING_PACKAGE_MANAGER_VCPKG=1 \ -DCMAKE_TOOLCHAIN_FILE="$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake" \ ..-- Running vcpkg installFetching registry information from g...@github.com:retifrav/vcpkg-registry.git (HEAD)...Detecting compiler hash for triplet x64-osx...The following packages will be built and installed: dearimgui[backend-glfw,core]:x64-osx -> 1.88.0 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/c3282e78368406b65f57ef0e3afa7cda2fc26501 * decovar-vcpkg-cmake[core]:x64-osx -> 2022-10-15 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/4ceb1e31d28a155bcbeb26382478b024a3d82cd3 glad[core]:x64-osx -> 0.1.36 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/2341f5144ce8e76a256289517d61abb4ab9fb72c glfw[core]:x64-osx -> 3.3.8 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/597fa07e1afd57c50dfdbeb0c0d28f4157748564 * vcpkg-cmake[core]:x64-osx -> 2022-08-18 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/84c200e8e625d4d99b1649525fcdf81a73197078 * vcpkg-cmake-config[core]:x64-osx -> 2022-02-06 -- /Users/USERNAME/.cache/vcpkg/registries/git-trees/e23b39e21f0dd42ecc615262640d211c39696aa1Additional packages (*) will be modified to complete this operation.Restored 6 package(s) from /Users/USERNAME/.cache/vcpkg/archives in 74.03 ms. Use --debug to see more details.Installing 1/6 vcpkg-cmake-config:x64-osx...Elapsed time to handle vcpkg-cmake-config:x64-osx: 5.364 msInstalling 2/6 vcpkg-cmake:x64-osx...Elapsed time to handle vcpkg-cmake:x64-osx: 4.532 msInstalling 3/6 decovar-vcpkg-cmake:x64-osx...Elapsed time to handle decovar-vcpkg-cmake:x64-osx: 6.853 msInstalling 4/6 glfw:x64-osx...Elapsed time to handle glfw:x64-osx: 14.2 msInstalling 5/6 dearimgui:x64-osx...Elapsed time to handle dearimgui:x64-osx: 31.32 msInstalling 6/6 glad:x64-osx...Elapsed time to handle glad:x64-osx: 31.76 msTotal elapsed time: 4.212 sglfw provides CMake targets: # this is heuristically generated, and may not be correct find_package(glfw3 CONFIG REQUIRED) target_link_libraries(main PRIVATE glfw)dearimgui provides CMake targets: # this is heuristically generated, and may not be correct find_package(dearimgui CONFIG REQUIRED) target_link_libraries(main PRIVATE dearimgui)glad provides CMake targets: # this is heuristically generated, and may not be correct find_package(glad CONFIG REQUIRED) target_link_libraries(main PRIVATE glad::glad)-- Running vcpkg install - done-- The C compiler identification is AppleClang 14.0.0.14000029-- The CXX compiler identification is AppleClang 14.0.0.14000029-- Detecting C compiler ABI info-- Detecting C compiler ABI info - done-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped-- Detecting C compile features-- Detecting C compile features - done-- Detecting CXX compiler ABI info-- Detecting CXX compiler ABI info - done-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped-- Detecting CXX compile features-- Detecting CXX compile features - done-- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/System/Library/Frameworks/OpenGL.framework-- Configuring done-- Generating done-- Build files have been written to: /path/to/glfw-imgui-example/build
So it just does not accept this, and indeed, setting it like "version>=": "3.3.8" will succeed, but then it will accept newer versions too, when they become available in the registry and it should not pick up newer versions, because vcpkg uses a minimum version approach. Unless, like I said before, if you set a dependency version with version>= and that value is lower than baselined version, then vcpkg will skip all the versions between that one and the baselined and will take the baselined version.
and rebuild the project, it will then fetch the GLFW sources for version 3.3.7 and build it (as there is only 3.3.8 pre-built in the cache), and it will also re-build Dear ImGui, because it one depends on GLFW:
Since we are brought up the subject of linking, in case you are curious, with Windows build as an example, if we build that project with vcpkg-default-triplet preset, which uses dynamic linking (VCPKG_LIBRARY_LINKAGE), then resulting artifacts will be all its dependencies as DLLs and a small executable of the application itself:
and then the toolchain (one of the /path/to/vcpkg/scripts/toolchains/*.cmake ones) will use these variables to set the CMAKE_*_FLAGS_INIT variables, which in turn will be used to set the CMAKE_*_FLAGS variables, which are the flags we are after.
As this StackOverflow thread says, the __CxxFrameHandler4 is a part of the newer FH4 exception handling, which apparently appeared in MSVC 142 toolset and newer, and so the resolution is to tell vcpkg to build dependencies using the same toolset as the one used to build the project.
I suspected that there might be some optimization flags not set, and I was almost right, although the other way around - turns out, by default vcpkg sets Debug flag /Z7 for Release configuration! See for yourself in the Windows toolchain (/path/to/vcpkg/scripts/toolchains/windows.cmake):
df19127ead