Techt3o commited on
Commit
9847acb
·
verified ·
1 Parent(s): caf1218

fafaab93548bb98a66091e2bf073feff65d2018e3254e19acf67a3a32d6a550d

Browse files
Files changed (50) hide show
  1. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/patching.md +220 -0
  2. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/CMakeLists.txt +5 -0
  3. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/compile.sh +54 -0
  4. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/my_lib.cpp +8 -0
  5. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/CMakeLists.txt +13 -0
  6. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/cmake/vcpkg_android.cmake +99 -0
  7. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/compile.sh +37 -0
  8. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/my_lib.cpp +8 -0
  9. third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/versioning.getting-started.md +251 -0
  10. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/authoring-script-ports.md +45 -0
  11. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/cmake-guidelines.md +166 -0
  12. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/control-files.md +205 -0
  13. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/execute_process.md +11 -0
  14. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_apply_patches.md +32 -0
  15. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_forward_output_variable.md +38 -0
  16. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_function_arguments.md +29 -0
  17. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_get_cmake_vars.md +36 -0
  18. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_prettify_command_line.md +21 -0
  19. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/maintainer-guide.md +418 -0
  20. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/manifest-files.md +551 -0
  21. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/portfile-functions.md +83 -0
  22. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake-config.md +10 -0
  23. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md +54 -0
  24. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake.md +7 -0
  25. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_build.md +38 -0
  26. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_configure.md +93 -0
  27. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_get_vars.md +41 -0
  28. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_install.md +25 -0
  29. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-pkgconfig-get-modules.md +6 -0
  30. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-pkgconfig-get-modules/x_vcpkg_pkgconfig_get_modules.md +45 -0
  31. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/pr-review-checklist.md +115 -0
  32. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/registries.md +365 -0
  33. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_acquire_msys.md +60 -0
  34. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_add_to_path.md +27 -0
  35. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_apply_patches.md +18 -0
  36. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_backup_restore_env_vars.md +26 -0
  37. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_cmake.md +38 -0
  38. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_make.md +57 -0
  39. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_msbuild.md +66 -0
  40. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_ninja.md +19 -0
  41. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_nmake.md +72 -0
  42. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_qmake.md +12 -0
  43. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_buildpath_length_warning.md +16 -0
  44. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_check_features.md +136 -0
  45. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_check_linkage.md +38 -0
  46. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_clean_executables_in_bin.md +25 -0
  47. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_clean_msbuild.md +17 -0
  48. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_common_definitions.md +36 -0
  49. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_configure_cmake.md +87 -0
  50. third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_configure_gn.md +34 -0
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/patching.md ADDED
@@ -0,0 +1,220 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ ## Patching Example: Patching libpng to work for x64-uwp
2
+
3
+ ### Initial error logs
4
+ First, try building:
5
+
6
+ ```no-highlight
7
+ PS D:\src\vcpkg> vcpkg install libpng:x64-uwp --editable
8
+ Computing installation plan...
9
+ The following packages will be built and installed:
10
+ libpng[core]:x64-uwp
11
+ Starting package 1/1: libpng:x64-uwp
12
+ Building package libpng[core]:x64-uwp...
13
+ -- Using cached D:/src/vcpkg/downloads/glennrp-libpng-v1.6.37.tar.gz
14
+ -- Extracting source D:/src/vcpkg/downloads/glennrp-libpng-v1.6.37.tar.gz
15
+ -- Using source at D:/src/vcpkg/buildtrees/libpng/src/v1.6.37-c993153cdf
16
+ -- Configuring x64-uwp
17
+ -- Building x64-uwp-rel
18
+ CMake Error at scripts/cmake/execute_required_process.cmake:14 (message):
19
+ Command failed: C:/Program Files/CMake/bin/cmake.exe;--build;.;--config;Release
20
+
21
+ Working Directory: D:/src/vcpkg/buildtrees/libpng/x64-uwp-rel
22
+
23
+ See logs for more information:
24
+
25
+ D:\src\vcpkg\buildtrees\libpng\build-x64-uwp-rel-out.log
26
+ D:\src\vcpkg\buildtrees\libpng\build-x64-uwp-rel-err.log
27
+
28
+ Call Stack (most recent call first):
29
+ scripts/cmake/vcpkg_build_cmake.cmake:3 (execute_required_process)
30
+ ports/libpng/portfile.cmake:22 (vcpkg_build_cmake)
31
+ scripts/ports.cmake:84 (include)
32
+
33
+
34
+ Error: build command failed
35
+ ```
36
+
37
+ Next, looking at the above logs (build-xxx-out.log and build-xxx-err.log).
38
+
39
+ ```no-highlight
40
+ // build-x64-uwp-rel-out.log
41
+ ...
42
+ "D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\ALL_BUILD.vcxproj" (default target) (1) ->
43
+ "D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\png.vcxproj" (default target) (3) ->
44
+ (ClCompile target) ->
45
+ D:\src\vcpkg\buildtrees\libpng\src\v1.6.37-c993153cdf\pngerror.c(775): warning C4013: 'ExitProcess' undefined; assuming extern returning int [D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\png.vcxproj]
46
+
47
+
48
+ "D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\ALL_BUILD.vcxproj" (default target) (1) ->
49
+ "D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\png.vcxproj" (default target) (3) ->
50
+ (Link target) ->
51
+ pngerror.obj : error LNK2019: unresolved external symbol _ExitProcess referenced in function _png_longjmp [D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\png.vcxproj]
52
+ D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\Release\libpng16.dll : fatal error LNK1120: 1 unresolved externals [D:\src\vcpkg\buildtrees\libpng\x64-uwp-rel\png.vcxproj]
53
+
54
+ 1 Warning(s)
55
+ 2 Error(s)
56
+
57
+ Time Elapsed 00:00:04.19
58
+ ```
59
+
60
+ ### Identify the problematic code
61
+
62
+ Taking a look at [MSDN](https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx) shows that `ExitProcess` is only available for desktop apps. Additionally, it's useful to see the surrounding context:
63
+
64
+ ```c
65
+ /* buildtrees\libpng\src\v1.6.37-c993153cdf\pngerror.c:769 */
66
+ /* If control reaches this point, png_longjmp() must not return. The only
67
+ * choice is to terminate the whole process (or maybe the thread); to do
68
+ * this the ANSI-C abort() function is used unless a different method is
69
+ * implemented by overriding the default configuration setting for
70
+ * PNG_ABORT().
71
+ */
72
+ PNG_ABORT();
73
+ ```
74
+
75
+ A recursive search for `PNG_ABORT` reveals the definition:
76
+ ```no-highlight
77
+ PS D:\src\vcpkg\buildtrees\libpng\src\v1.6.37-c993153cdf> findstr /snipl "PNG_ABORT" *
78
+ CHANGES:701: Added PNG_SETJMP_SUPPORTED, PNG_SETJMP_NOT_SUPPORTED, and PNG_ABORT() macros
79
+ libpng-manual.txt:432:errors will result in a call to PNG_ABORT() which defaults to abort().
80
+ libpng-manual.txt:434:You can #define PNG_ABORT() to a function that does something
81
+ libpng-manual.txt:2753:errors will result in a call to PNG_ABORT() which defaults to abort().
82
+ libpng-manual.txt:2755:You can #define PNG_ABORT() to a function that does something
83
+ libpng-manual.txt:4226:PNG_NO_SETJMP, in which case it is handled via PNG_ABORT()),
84
+ libpng.3:942:errors will result in a call to PNG_ABORT() which defaults to abort().
85
+ libpng.3:944:You can #define PNG_ABORT() to a function that does something
86
+ libpng.3:3263:errors will result in a call to PNG_ABORT() which defaults to abort().
87
+ libpng.3:3265:You can #define PNG_ABORT() to a function that does something
88
+ libpng.3:4736:PNG_NO_SETJMP, in which case it is handled via PNG_ABORT()),
89
+ png.h:994: * will use it; otherwise it will call PNG_ABORT(). This function was
90
+ pngerror.c:773: * PNG_ABORT().
91
+ pngerror.c:775: PNG_ABORT();
92
+ pngpriv.h:459:#ifndef PNG_ABORT
93
+ pngpriv.h:461:# define PNG_ABORT() ExitProcess(0)
94
+ pngpriv.h:463:# define PNG_ABORT() abort()
95
+ ```
96
+
97
+ This already gives us some great clues, but the full definition tells the complete story.
98
+
99
+ ```c
100
+ /* buildtrees\libpng\src\v1.6.37-c993153cdf\pngpriv.h:459 */
101
+ #ifndef PNG_ABORT
102
+ # ifdef _WINDOWS_
103
+ # define PNG_ABORT() ExitProcess(0)
104
+ # else
105
+ # define PNG_ABORT() abort()
106
+ # endif
107
+ #endif
108
+ ```
109
+
110
+ `abort()` is a standard CRT call and certainly available in UWP, so we just need to convince libpng to be more platform agnostic. The easiest and most reliable way to achieve this is to patch the code; while in this particular case we could pass in a compiler flag to override `PNG_ABORT` because this is a private header, in general it is more reliable to avoid adding more required compiler switches when possible (especially when it isn't already exposed as a CMake option).
111
+
112
+ ### Patching the code to improve compatibility
113
+
114
+ We recommend using git to create the patch file, since you'll already have it installed.
115
+ ```no-highlight
116
+ PS D:\src\vcpkg\buildtrees\libpng\src\v1.6.37-c993153cdf> git init .
117
+ Initialized empty Git repository in D:/src/vcpkg/buildtrees/libpng/src/v1.6.37-c993153cdf/.git/
118
+
119
+ PS D:\src\vcpkg\buildtrees\libpng\src\v1.6.37-c993153cdf> git add .
120
+ warning: LF will be replaced by CRLF in ANNOUNCE.
121
+ The file will have its original line endings in your working directory.
122
+ ...
123
+
124
+ PS D:\src\vcpkg\buildtrees\libpng\src\v1.6.37-c993153cdf> git commit -m "temp"
125
+ [master (root-commit) 68f253f] temp
126
+ 422 files changed, 167717 insertions(+)
127
+ ...
128
+ ```
129
+
130
+ Now we can modify `pngpriv.h` to use `abort()` everywhere.
131
+ ```c
132
+ /* buildtrees\libpng\src\v1.6.37-c993153cdf\pngpriv.h:459 */
133
+ #ifndef PNG_ABORT
134
+ # define PNG_ABORT() abort()
135
+ #endif
136
+ ```
137
+
138
+ The output of `git diff` is already in patch format, so we just need to save the patch into the `ports/libpng` directory.
139
+ ```no-highlight
140
+ PS buildtrees\libpng\src\v1.6.37-c993153cdf> git diff --ignore-space-at-eol | out-file -enc ascii ..\..\..\..\ports\libpng\use-abort-on-all-platforms.patch
141
+ ```
142
+
143
+ Finally, we need to apply the patch after extracting the source.
144
+ ```cmake
145
+ # ports\libpng\portfile.cmake
146
+ ...
147
+ vcpkg_extract_source_archive_ex(
148
+ OUT_SOURCE_PATH SOURCE_PATH
149
+ ARCHIVE ${ARCHIVE}
150
+ PATCHES
151
+ "use-abort-on-all-platforms.patch"
152
+ )
153
+
154
+ vcpkg_cmake_configure(
155
+ ...
156
+ ```
157
+
158
+ ### Verification
159
+
160
+ To be completely sure this works from scratch, we need to remove the package and rebuild it:
161
+
162
+ ```no-highlight
163
+ PS D:\src\vcpkg> vcpkg remove libpng:x64-uwp
164
+ Package libpng:x64-uwp was successfully removed
165
+ ```
166
+
167
+ Now we try a fresh, from scratch install.
168
+
169
+ ```no-highlight
170
+ PS D:\src\vcpkg> vcpkg install libpng:x64-uwp
171
+ Computing installation plan...
172
+ The following packages will be built and installed:
173
+ libpng[core]:x64-uwp
174
+ Starting package 1/1: libpng:x64-uwp
175
+ Building package libpng[core]:x64-uwp...
176
+ Could not locate cached archive: C:\Users\me\AppData\Local\vcpkg/archives\f4\f44b54f818f78b9a4ccd34b3666f566f94286850.zip
177
+ -- Using cached D:/src/vcpkg/downloads/glennrp-libpng-v1.6.37.tar.gz
178
+ -- Extracting source D:/src/vcpkg/downloads/glennrp-libpng-v1.6.37.tar.gz
179
+ -- Applying patch use_abort.patch
180
+ -- Applying patch cmake.patch
181
+ -- Applying patch pkgconfig.patch
182
+ -- Applying patch pkgconfig.2.patch
183
+ -- Using source at D:/src/vcpkg/buildtrees/libpng/src/v1.6.37-10db9f58e4.clean
184
+ -- Configuring x64-uwp
185
+ -- Building x64-uwp-dbg
186
+ -- Building x64-uwp-rel
187
+ -- Fixing pkgconfig file: D:/src/vcpkg/packages/libpng_x64-uwp/lib/pkgconfig/libpng.pc
188
+ -- Fixing pkgconfig file: D:/src/vcpkg/packages/libpng_x64-uwp/lib/pkgconfig/libpng16.pc
189
+ -- Fixing pkgconfig file: D:/src/vcpkg/packages/libpng_x64-uwp/debug/lib/pkgconfig/libpng.pc
190
+ -- Fixing pkgconfig file: D:/src/vcpkg/packages/libpng_x64-uwp/debug/lib/pkgconfig/libpng16.pc
191
+ -- Installing: D:/src/vcpkg/packages/libpng_x64-uwp/share/libpng/copyright
192
+ -- Performing post-build validation
193
+ -- Performing post-build validation done
194
+ Stored binary cache: C:\Users\me\AppData\Local\vcpkg/archives\f4\f44b54f818f78b9a4ccd34b3666f566f94286850.zip
195
+ Building package libpng[core]:x64-uwp... done
196
+ Installing package libpng[core]:x64-uwp...
197
+ Installing package libpng[core]:x64-uwp... done
198
+ Elapsed time for package libpng:x64-uwp: 11.94 s
199
+
200
+ Total elapsed time: 11.95 s
201
+
202
+ The package libpng:x64-uwp provides CMake targets:
203
+
204
+ find_package(libpng CONFIG REQUIRED)
205
+ target_link_libraries(main PRIVATE png)
206
+ ```
207
+
208
+ Finally, to fully commit and publish the changes, we need to bump the port version in `vcpkg.json`,
209
+ and add the patch file to source control, then make a Pull Request!
210
+
211
+ ```json
212
+ {
213
+ "name": "libpng",
214
+ "version": "1.6.37",
215
+ "port-version": 1,
216
+ "dependencies": [
217
+ "zlib"
218
+ ]
219
+ }
220
+ ```
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/CMakeLists.txt ADDED
@@ -0,0 +1,5 @@
 
 
 
 
 
 
1
+ cmake_minimum_required(VERSION 3.0)
2
+ project(test)
3
+ find_package(jsoncpp CONFIG REQUIRED)
4
+ add_library(my_lib my_lib.cpp)
5
+ target_link_libraries(my_lib jsoncpp_lib)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/compile.sh ADDED
@@ -0,0 +1,54 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ #
2
+ # 1. Check the presence of required environment variables
3
+ #
4
+ if [ -z ${ANDROID_NDK_HOME+x} ]; then
5
+ echo "Please set ANDROID_NDK_HOME"
6
+ exit 1
7
+ fi
8
+ if [ -z ${VCPKG_ROOT+x} ]; then
9
+ echo "Please set VCPKG_ROOT"
10
+ exit 1
11
+ fi
12
+
13
+ #
14
+ # 2. Set the path to the toolchains
15
+ #
16
+ vcpkg_toolchain_file=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
17
+ android_toolchain_file=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake
18
+
19
+
20
+ #
21
+ # 3. Select a pair "Android abi" / "vcpkg triplet"
22
+ # Uncomment one of the four possibilities below
23
+ #
24
+
25
+ android_abi=armeabi-v7a
26
+ vcpkg_target_triplet=arm-android
27
+
28
+ # android_abi=x86
29
+ # vcpkg_target_triplet=x86-android
30
+
31
+ # android_abi=arm64-v8a
32
+ # vcpkg_target_triplet=arm64-android
33
+
34
+ # android_abi=x86_64
35
+ # vcpkg_target_triplet=x64-android
36
+
37
+
38
+ #
39
+ # 4. Install the library via vcpkg
40
+ #
41
+ $VCPKG_ROOT/vcpkg install jsoncpp:$vcpkg_target_triplet
42
+
43
+ #
44
+ # 5. Test the build
45
+ #
46
+ rm -rf build
47
+ mkdir build
48
+ cd build
49
+ cmake .. \
50
+ -DCMAKE_TOOLCHAIN_FILE=$vcpkg_toolchain_file \
51
+ -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=$android_toolchain_file \
52
+ -DVCPKG_TARGET_TRIPLET=$vcpkg_target_triplet \
53
+ -DANDROID_ABI=$android_abi
54
+ make
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake/my_lib.cpp ADDED
@@ -0,0 +1,8 @@
 
 
 
 
 
 
 
 
 
1
+ #include <json/json.h>
2
+
3
+ int answer()
4
+ {
5
+ Json::Value meaning_of;
6
+ meaning_of["everything"] = 42;
7
+ return meaning_of["everything"].asInt();
8
+ }
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/CMakeLists.txt ADDED
@@ -0,0 +1,13 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ cmake_minimum_required(VERSION 3.0)
2
+
3
+ # if -DVCPKG_TARGET_ANDROID=ON is specified when invoking cmake, load cmake/vcpkg_android.cmake
4
+ # !!! Important: place this line before calling project() !!!
5
+ if (VCPKG_TARGET_ANDROID)
6
+ include("cmake/vcpkg_android.cmake")
7
+ endif()
8
+
9
+ project(test)
10
+
11
+ find_package(jsoncpp CONFIG REQUIRED)
12
+ add_library(my_lib my_lib.cpp)
13
+ target_link_libraries(my_lib JsonCpp::JsonCpp)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/cmake/vcpkg_android.cmake ADDED
@@ -0,0 +1,99 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ #
2
+ # vcpkg_android.cmake
3
+ #
4
+ # Helper script when using vcpkg with cmake. It should be triggered via the variable VCPKG_TARGET_ANDROID
5
+ #
6
+ # For example:
7
+ # if (VCPKG_TARGET_ANDROID)
8
+ # include("cmake/vcpkg_android.cmake")
9
+ # endif()
10
+ #
11
+ # This script will:
12
+ # 1 & 2. check the presence of needed env variables: ANDROID_NDK_HOME and VCPKG_ROOT
13
+ # 3. set VCPKG_TARGET_TRIPLET according to ANDROID_ABI
14
+ # 4. Combine vcpkg and Android toolchains by setting CMAKE_TOOLCHAIN_FILE
15
+ # and VCPKG_CHAINLOAD_TOOLCHAIN_FILE
16
+
17
+ # Note: VCPKG_TARGET_ANDROID is not an official Vcpkg variable.
18
+ # it is introduced for the need of this script
19
+
20
+ if (VCPKG_TARGET_ANDROID)
21
+
22
+ #
23
+ # 1. Check the presence of environment variable ANDROID_NDK_HOME
24
+ #
25
+ if (NOT DEFINED ENV{ANDROID_NDK_HOME})
26
+ message(FATAL_ERROR "
27
+ Please set an environment variable ANDROID_NDK_HOME
28
+ For example:
29
+ export ANDROID_NDK_HOME=/home/your-account/Android/Sdk/ndk-bundle
30
+ Or:
31
+ export ANDROID_NDK_HOME=/home/your-account/Android/android-ndk-r21b
32
+ ")
33
+ endif()
34
+
35
+ #
36
+ # 2. Check the presence of environment variable VCPKG_ROOT
37
+ #
38
+ if (NOT DEFINED ENV{VCPKG_ROOT})
39
+ message(FATAL_ERROR "
40
+ Please set an environment variable VCPKG_ROOT
41
+ For example:
42
+ export VCPKG_ROOT=/path/to/vcpkg
43
+ ")
44
+ endif()
45
+
46
+
47
+ #
48
+ # 3. Set VCPKG_TARGET_TRIPLET according to ANDROID_ABI
49
+ #
50
+ # There are four different Android ABI, each of which maps to
51
+ # a vcpkg triplet. The following table outlines the mapping from vcpkg architectures to android architectures
52
+ #
53
+ # |VCPKG_TARGET_TRIPLET | ANDROID_ABI |
54
+ # |---------------------------|----------------------|
55
+ # |arm64-android | arm64-v8a |
56
+ # |arm-android | armeabi-v7a |
57
+ # |x64-android | x86_64 |
58
+ # |x86-android | x86 |
59
+ #
60
+ # The variable must be stored in the cache in order to successfully the two toolchains.
61
+ #
62
+ if (ANDROID_ABI MATCHES "arm64-v8a")
63
+ set(VCPKG_TARGET_TRIPLET "arm64-android" CACHE STRING "" FORCE)
64
+ elseif(ANDROID_ABI MATCHES "armeabi-v7a")
65
+ set(VCPKG_TARGET_TRIPLET "arm-android" CACHE STRING "" FORCE)
66
+ elseif(ANDROID_ABI MATCHES "x86_64")
67
+ set(VCPKG_TARGET_TRIPLET "x64-android" CACHE STRING "" FORCE)
68
+ elseif(ANDROID_ABI MATCHES "x86")
69
+ set(VCPKG_TARGET_TRIPLET "x86-android" CACHE STRING "" FORCE)
70
+ else()
71
+ message(FATAL_ERROR "
72
+ Please specify ANDROID_ABI
73
+ For example
74
+ cmake ... -DANDROID_ABI=armeabi-v7a
75
+
76
+ Possible ABIs are: arm64-v8a, armeabi-v7a, x64-android, x86-android
77
+ ")
78
+ endif()
79
+ message("vcpkg_android.cmake: VCPKG_TARGET_TRIPLET was set to ${VCPKG_TARGET_TRIPLET}")
80
+
81
+
82
+ #
83
+ # 4. Combine vcpkg and Android toolchains
84
+ #
85
+
86
+ # vcpkg and android both provide dedicated toolchains:
87
+ #
88
+ # vcpkg_toolchain_file=$VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake
89
+ # android_toolchain_file=$ANDROID_NDK_HOME/build/cmake/android.toolchain.cmake
90
+ #
91
+ # When using vcpkg, the vcpkg toolchain shall be specified first.
92
+ # However, vcpkg provides a way to preload and additional toolchain,
93
+ # with the VCPKG_CHAINLOAD_TOOLCHAIN_FILE option.
94
+ set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE $ENV{ANDROID_NDK_HOME}/build/cmake/android.toolchain.cmake)
95
+ set(CMAKE_TOOLCHAIN_FILE $ENV{VCPKG_ROOT}/scripts/buildsystems/vcpkg.cmake)
96
+ message("vcpkg_android.cmake: CMAKE_TOOLCHAIN_FILE was set to ${CMAKE_TOOLCHAIN_FILE}")
97
+ message("vcpkg_android.cmake: VCPKG_CHAINLOAD_TOOLCHAIN_FILE was set to ${VCPKG_CHAINLOAD_TOOLCHAIN_FILE}")
98
+
99
+ endif(VCPKG_TARGET_ANDROID)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/compile.sh ADDED
@@ -0,0 +1,37 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # 1. Install the library via vcpkg
2
+ # This install jsoncpp for the 4 android target ABIs and for the host computer.
3
+ # see the correspondence between ABIs and vcpkg triplets in the table below:
4
+ #
5
+ # |VCPKG_TARGET_TRIPLET | ANDROID_ABI |
6
+ # |---------------------------|----------------------|
7
+ # |arm64-android | arm64-v8a |
8
+ # |arm-android | armeabi-v7a |
9
+ # |x64-android | x86_64 |
10
+ # |x86-android | x86 |
11
+ $VCPKG_ROOT/vcpkg install \
12
+ jsoncpp \
13
+ jsoncpp:arm-android \
14
+ jsoncpp:arm64-android \
15
+ jsoncpp:x86-android \
16
+ jsoncpp:x64-android
17
+
18
+
19
+ # 2. Test the build
20
+ #
21
+ # First, select an android ABI
22
+ # Uncomment one of the four possibilities below
23
+ #
24
+ android_abi=armeabi-v7a
25
+ # android_abi=x86
26
+ # android_abi=arm64-v8a
27
+ # android_abi=x86_64
28
+
29
+ rm -rf build
30
+ mkdir build && cd build
31
+
32
+ # DVCPKG_TARGET_ANDROID will load vcpkg_android.cmake,
33
+ # which will then load the android + vcpkg toolchains.
34
+ cmake .. \
35
+ -DVCPKG_TARGET_ANDROID=ON \
36
+ -DANDROID_ABI=$android_abi
37
+ make
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/vcpkg_android_example_cmake_script/my_lib.cpp ADDED
@@ -0,0 +1,8 @@
 
 
 
 
 
 
 
 
 
1
+ #include <json/json.h>
2
+
3
+ int answer()
4
+ {
5
+ Json::Value meaning_of;
6
+ meaning_of["everything"] = 42;
7
+ return meaning_of["everything"].asInt();
8
+ }
third-party/DPVO/Pangolin/scripts/vcpkg/docs/examples/versioning.getting-started.md ADDED
@@ -0,0 +1,251 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Getting started with versioning
2
+
3
+ **The latest version of this documentation is available on [GitHub](https://github.com/Microsoft/vcpkg/tree/master/docs/examples/versioning.getting-started.md).**
4
+
5
+ Vcpkg lets you take control of which version of packages to install in your projects using manifests.
6
+
7
+ ## Using versions with manifests
8
+
9
+ With the `versions` feature flag enabled you can start adding version constraints to your dependencies.
10
+
11
+ Let's start with creating a simple CMake project that depends on `fmt` and `zlib`.
12
+
13
+ Create a folder with the following files:
14
+
15
+ **vcpkg.json**
16
+ ```json
17
+ {
18
+ "name": "versions-test",
19
+ "version": "1.0.0",
20
+ "dependencies": [
21
+ {
22
+ "name": "fmt",
23
+ "version>=": "7.1.3#1"
24
+ },
25
+ "zlib"
26
+ ],
27
+ "builtin-baseline": "3426db05b996481ca31e95fff3734cf23e0f51bc"
28
+ }
29
+ ```
30
+
31
+ **main.cpp**
32
+ ```c++
33
+ #include <fmt/core.h>
34
+ #include <zlib.h>
35
+
36
+ int main()
37
+ {
38
+ fmt::print("fmt version is {}\n"
39
+ "zlib version is {}\n",
40
+ FMT_VERSION, ZLIB_VERSION);
41
+ return 0;
42
+ }
43
+ ```
44
+
45
+ **CMakeLists.txt**
46
+ ```CMake
47
+ cmake_minimum_required(VERSION 3.18)
48
+
49
+ project(versionstest CXX)
50
+
51
+ add_executable(main main.cpp)
52
+
53
+ find_package(ZLIB REQUIRED)
54
+ find_package(fmt CONFIG REQUIRED)
55
+ target_link_libraries(main PRIVATE ZLIB::ZLIB fmt::fmt)
56
+ ```
57
+
58
+ And now we build and run our project with CMake:
59
+
60
+ 1. Create the build directory for the project.
61
+ ```
62
+ PS D:\versions-test> mkdir build
63
+ PS D:\versions-test> cd build
64
+ ```
65
+
66
+ 2. Configure CMake.
67
+ ```
68
+ PS D:\versions-test\build> cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake ..
69
+ -- Running vcpkg install
70
+ Detecting compiler hash for triplet x86-windows...
71
+ The following packages will be built and installed:
72
+ fmt[core]:x64-windows -> 7.1.3#1 -- D:\Work\viromer\vcpkg\buildtrees\versioning\versions\fmt\4f8427eb0bd40da1856d4e67bde39a4fda689d72
73
+ vcpkg-cmake[core]:x64-windows -> 2021-02-26 -- D:\Work\viromer\vcpkg\buildtrees\versioning\versions\vcpkg-cmake\51896aa8073adb5c8450daa423d03eedf0dfc61f
74
+ vcpkg-cmake-config[core]:x64-windows -> 2021-02-26 -- D:\Work\viromer\vcpkg\buildtrees\versioning\versions\vcpkg-cmake-config\d255b3d566a8861dcc99a958240463e678528066
75
+ zlib[core]:x64-windows -> 1.2.11#9 -- D:\Work\viromer\vcpkg\buildtrees\versioning\versions\zlib\827111046e37c98153d9d82bb6fa4183b6d728e4
76
+ ...
77
+ ```
78
+
79
+ 3. Build the project.
80
+ ```
81
+ PS D:\versions-test\build> cmake --build .
82
+ [2/2] Linking CXX executable main.exe
83
+ ```
84
+
85
+ 4. Run it!
86
+ ```
87
+ PS D:\versions-test\build> ./main.exe
88
+ fmt version is 70103
89
+ zlib version is 1.2.11
90
+ ```
91
+
92
+ Take a look at the output:
93
+
94
+ ```
95
+ fmt[core]:x86-windows -> 7.1.3#1 -- D:\vcpkg\buildtrees\versioning\versions\fmt\4f8427eb0bd40da1856d4e67bde39a4fda689d72
96
+ ...
97
+ zlib[core]:x86-windows -> 1.2.11#9 -- D:\vcpkg\buildtrees\versioning\versions\zlib\827111046e37c98153d9d82bb6fa4183b6d728e4
98
+ ```
99
+
100
+ Instead of using the portfiles in `ports/`, vcpkg is checking out the files for each version in `buildtrees/versioning/versions/`. The files in `ports/` are still used when running vcpkg in classic mode or when the `versions` feature flag is disabled.
101
+
102
+ _NOTE: Output from vcpkg while configuring CMake is only available when using CMake version `3.18` or newer. If you're using an older CMake you can check the `vcpkg-manifest-install.log` file in your build directory instead._
103
+
104
+ Read our [manifests announcement blog post](https://devblogs.microsoft.com/cppblog/vcpkg-accelerate-your-team-development-environment-with-binary-caching-and-manifests/#using-manifests-with-msbuild-projects) to learn how to use manifests with MSBuild.
105
+
106
+ ### Manifest changes
107
+ If you have used manifests before you will notice that there are some new JSON properties. Let's review these changes:
108
+
109
+ #### **`version`**
110
+ ```json
111
+ {
112
+ "name": "versions-test",
113
+ "version": "1.0.0"
114
+ }
115
+ ```
116
+
117
+ This is your project's version declaration. Previously, you could only declare versions for your projects using the `version-string` property. Now that versioning has come around, vcpkg is aware of some new versioning schemes.
118
+
119
+ Version scheme | Description
120
+ ---------------- | ---------------
121
+ `version` | Dot-separated numerics: `1.0.0.5`.
122
+ `version-semver` | Compliant [semantic versions](https://semver.org): `1.2.0` and `1.2.0-rc`.
123
+ `version-date` | Dates in `YYYY-MM-DD` format: `2021-01-01`
124
+ `version-string` | Arbitrary strings: `vista`, `candy`.
125
+
126
+ #### **`version>=`**
127
+ ```json
128
+ {
129
+ "dependencies": [
130
+ { "name": "fmt", "version>=": "7.1.3" },
131
+ "zlib"
132
+ ]
133
+ }
134
+ ```
135
+
136
+ This property is used to express minimum version constraints, it is allowed only as part of the `"dependencies"` declarations. In our example we set an explicit constraint on version `7.1.3#1` of `fmt`.
137
+
138
+ Vcpkg is allowed to upgrade this constraint if a transitive dependency requires a newer version. For example, if `zlib` were to declare a dependency on `fmt` version `7.1.4` then vcpkg would install `7.1.4` instead.
139
+
140
+ Vcpkg uses a minimum version approach, in our example, even if `fmt` version `8.0.0` were to be released, vcpkg would still install version `7.1.3#1` as that is the minimum version that satisfies the constraint. The advantages of this approach are that you don't get unexpected dependency upgrades when you update vcpkg and you get reproducible builds (in terms of version used) as long as you use the same manifest.
141
+
142
+ If you want to upgrade your dependencies, you can bump the minimum version constraint or use a newer baseline.
143
+
144
+ #### **`builtin-baseline`**
145
+
146
+ ```json
147
+ { "builtin-baseline": "3426db05b996481ca31e95fff3734cf23e0f51bc" }
148
+ ```
149
+
150
+ This field declares the versioning baseline for all ports. Setting a baseline is required to enable versioning, otherwise you will get the current versions on the ports directory. You can run 'git rev-parse HEAD' to get the current commit of vcpkg and set it as the builtin-baseline. See the [`builtin-baseline` documentation](../users/versioning.md#builtin-baseline) for more information.
151
+
152
+ In our example, you can notice that we do not declare a version constraint for `zlib`; instead, the version is taken from the baseline. Internally, vcpkg will look in commit `3426db05b996481ca31e95fff3734cf23e0f51bc` to find out what version of `zlib` was the latest at that point in time (in our case it was `1.2.11#9`).
153
+
154
+ During version resolution, baseline versions are treated as minimum version constraints. If you declare an explicit constraint that is lower than a baseline version, the explicit constraint will be upgraded to the baseline version.
155
+
156
+ For example, if we modified our dependencies like this:
157
+ ```json
158
+ { "dependencies": [
159
+ {
160
+ "name": "fmt",
161
+ "version>=": "7.1.3#1"
162
+ },
163
+ {
164
+ "name": "zlib",
165
+ "version>=": "1.2.11#7"
166
+ }
167
+ ] }
168
+ ```
169
+
170
+ _NOTE: The value `1.2.11#7` represents version `1.2.11`, port version `7`._
171
+
172
+ Since the baseline introduces a minimum version constraint for `zlib` at `1.2.11#9` and a higher version does satisfy the minimum version constraint for `1.2.11#7`, vcpkg is allowed to upgrade it.
173
+
174
+ Baselines are also a convenient mechanism to upgrade multiple versions at a time, for example, if you wanted to depend on multiple `boost` libraries, it is more convenient to set the `baseline` once than declaring a version constraint on each package.
175
+
176
+ But what if you want to pin a version older than the baseline?
177
+
178
+ #### **`overrides`**
179
+
180
+ Since baselines establish a version floor for all packages and explicit constraints get upgraded when they are lower than the baseline, we need another mechanism to downgrade versions past the baseline.
181
+
182
+ The mechanism vcpkg provides for that scenario is `overrides`. When an override is declared on a package, vcpkg will ignore all other version constraints either directly declared in the manifest or from transitive dependencies. In short, `overrides` will force vcpkg to use the exact version declared, period.
183
+
184
+ Let's modify our example once more, this time to force vcpkg to use version `6.0.0` of `fmt`.
185
+
186
+ ```json
187
+ {
188
+ "name": "versions-test",
189
+ "version": "1.0.0",
190
+ "dependencies": [
191
+ {
192
+ "name": "fmt",
193
+ "version>=": "7.1.3#1"
194
+ },
195
+ {
196
+ "name": "zlib",
197
+ "version>=": "1.2.11#7"
198
+ }
199
+ ],
200
+ "builtin-baseline": "3426db05b996481ca31e95fff3734cf23e0f51bc",
201
+ "overrides": [
202
+ {
203
+ "name": "fmt",
204
+ "version": "6.0.0"
205
+ }
206
+ ]
207
+ }
208
+ ```
209
+
210
+ Rebuild our project:
211
+
212
+ ```
213
+ PS D:\versions-test\build> rm ./CMakeCache.txt
214
+ PS D:\versions-test\build> rm -r ./vcpkg_installed
215
+ PS D:\versions-test\build> cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=D:/vcpkg/scripts/buildsystems/vcpkg.cmake ..
216
+ -- Running vcpkg install
217
+ Detecting compiler hash for triplet x86-windows...
218
+ The following packages will be built and installed:
219
+ fmt[core]:x86-windows -> 6.0.0 -- D:\vcpkg\buildtrees\versioning\versions\fmt\d99b6a35e1406ba6b6e09d719bebd086f83ed5f3
220
+ zlib[core]:x86-windows -> 1.2.11#9 -- D:\vcpkg\buildtrees\versioning\versions\zlib\827111046e37c98153d9d82bb6fa4183b6d728e4
221
+ ...
222
+ PS D:\versions-test\build> cmake --build .
223
+ [2/2] Linking CXX executable main.exe
224
+ ```
225
+
226
+ And run it!
227
+ ```
228
+ PS D:\versions-test\build> .\main.exe
229
+ fmt version is 60000
230
+ zlib version is 1.2.11
231
+ ```
232
+
233
+ Notice how the `fmt` is now at version `6.0.0` just like we wanted.
234
+
235
+ ## Versions and custom ports
236
+
237
+ The last thing to discuss is how overlay ports interact with versioning resolution. The answer is: they don't.
238
+
239
+ Going into more detail, when you provide an overlay for a port, vcpkg will always use the overlay port without caring what version is contained in it. The reasons are two-fold: (1) it is consistent with the existing behavior of overlay ports of completely masking the existing port, and (2) overlay ports do not (and are not expected to) provide enough information to power vcpkg's versioning feature.
240
+
241
+ If you want to have flexible port customization along with versioning features, you should consider making your own custom registry. See our [registries specification for more details](../specifications/registries.md).
242
+
243
+ ## Further reading
244
+
245
+ If you're interested in delving deeper into the details of how versioning works we recommended that you read the [original versioning specification](../specifications/versioning.md) and the [implementation details](../users/versioning.implementation-details.md).
246
+
247
+ See also:
248
+
249
+ * [Versioning docs](../users/versioning.md)
250
+ * [Original specification](../specifications/versioning.md)
251
+ * [Versioning implementation details](../users/versioning.implementation-details.md)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/authoring-script-ports.md ADDED
@@ -0,0 +1,45 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Authoring Script Ports
2
+
3
+ Ports can expose functions for other ports to consume during their build. For
4
+ example, the `vcpkg-cmake` helper port exposes the `vcpkg_cmake_configure()`
5
+ helper function. Packaging common scripts into a shared helper port makes
6
+ maintenance easier because all consumers can be updated from a single place.
7
+ Because the scripts come from a port, they can be versioned and depended upon
8
+ via all the same mechanisms as any other port.
9
+
10
+ Script ports are implemented via the `vcpkg-port-config.cmake` extension
11
+ mechanism. Before invoking the `portfile.cmake` of a port, vcpkg will first
12
+ import `share/<port>/vcpkg-port-config.cmake` from each direct dependency. If
13
+ the direct dependency is a host dependency, the import will be performed in the
14
+ host installed tree (e.g.
15
+ `${HOST_INSTALLED_DIR}/share/<port>/vcpkg-port-config.cmake`).
16
+
17
+ Only direct dependencies are considered for `vcpkg-port-config.cmake` inclusion.
18
+ This means that if a script port relies on another script port, it must
19
+ explicitly import the `vcpkg-port-config.cmake` of its dependency.
20
+
21
+ Script-to-script dependencies should not be marked as host. The dependency from
22
+ a target port to a script should be marked host, which means that scripts should
23
+ always already be natively compiling. By making script-to-script dependencies
24
+ `"host": false`, it ensures that one script can depend upon the other being in
25
+ its same install directory.
26
+
27
+ Ports should never provide a `vcpkg-port-config.cmake` file under a different
28
+ `share/` subdirectory than the current port (`${PORT}`).
29
+
30
+ ## Example
31
+
32
+ ```cmake
33
+ # ${CURRENT_PACKAGES_DIR}/share/my-helper/vcpkg-port-config.cmake
34
+
35
+ # This include guard ensures the file will be loaded only once
36
+ include_guard(GLOBAL)
37
+
38
+ # This is how you could pull in a transitive dependency
39
+ include("${CMAKE_CURRENT_LIST_DIR}/../my-other-helper/vcpkg-port-config.cmake")
40
+
41
+ # Finally, it is convention to put each public function into a separate file with a matching name
42
+ include("${CMAKE_CURRENT_LIST_DIR}/my_helper_function_01.cmake")
43
+ include("${CMAKE_CURRENT_LIST_DIR}/my_helper_function_02.cmake")
44
+ include("${CMAKE_CURRENT_LIST_DIR}/my_helper_function_03.cmake")
45
+ ```
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/cmake-guidelines.md ADDED
@@ -0,0 +1,166 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # CMake Guidelines
2
+
3
+ We expect that all CMake scripts that are either:
4
+
5
+ - In the `scripts/` directory, or
6
+ - In a `vcpkg-*` port
7
+
8
+ should follow the guidelines laid out in this document.
9
+ Existing scripts may not follow these guidelines yet;
10
+ it is expected that we will continue to update old scripts
11
+ to fall in line with these guidelines.
12
+
13
+ These guidelines are intended to create stability in our scripts.
14
+ We hope that they will make both forwards and backwards compatibility easier.
15
+
16
+ ## The Guidelines
17
+
18
+ - Except for out-parameters, we always use `cmake_parse_arguments()`
19
+ rather than function parameters or referring to `${ARG<N>}`.
20
+ - This doesn't necessarily need to be followed for "script-local helper functions"
21
+ - In this case, positional parameters should be put in the function
22
+ declaration (rather than using `${ARG<N>}`),
23
+ and should be named according to local rules (i.e. `snake_case`).
24
+ - Exception: positional parameters that are optional should be
25
+ given a name via `set(argument_name "${ARG<N>}")`, after checking `ARGC`.
26
+ - Out-parameters should be the first parameter to a function. Example:
27
+ ```cmake
28
+ function(format out_var)
29
+ cmake_parse_arguments(PARSE_ARGV 1 "arg" ...)
30
+ # ... set(buffer "output")
31
+ set("${out_var}" "${buffer}" PARENT_SCOPE)
32
+ endfunction()
33
+ ```
34
+ - There are no unparsed or unused arguments.
35
+ Always check for `ARGN` or `arg_UNPARSED_ARGUMENTS`.
36
+ `FATAL_ERROR` when possible, `WARNING` if necessary for backwards compatibility.
37
+ - All `cmake_parse_arguments` must use `PARSE_ARGV`.
38
+ - All `foreach` loops must use `IN LISTS`, `IN ITEMS`, or `RANGE`.
39
+ - The variables `${ARGV}` and `${ARGN}` are unreferenced,
40
+ except in helpful messages to the user.
41
+ - (i.e., `message(FATAL_ERROR "blah was passed extra arguments: ${ARGN}")`)
42
+ - We always use functions, not macros or top level code.
43
+ - Exception: "script-local helper macros". It is sometimes helpful to define a small macro.
44
+ This should be done sparingly, and functions should be preferred.
45
+ - Exception: `vcpkg.cmake`'s `find_package`.
46
+ - Scripts in the scripts tree should not be expected to need observable changes
47
+ as part of normal operation.
48
+ - Example violation: `vcpkg_acquire_msys()` has hard-coded packages and versions
49
+ that need updating over time due to the MSYS project dropping old packages.
50
+ - Example exception: `vcpkg_from_sourceforge()` has a list of mirrors which
51
+ needs maintenance, but does not have an observable behavior impact on the callers.
52
+ - Rules for quoting: there are three kinds of arguments in CMake -
53
+ unquoted (`foo(BAR)`), quoted (`foo("BAR")`), and bracketed (`foo([[BAR]])`).
54
+ Follow these rules to quote correctly:
55
+ - If an argument contains a variable expansion `${...}`,
56
+ it must be quoted.
57
+ - Exception: a "splat" variable expansion, when one variable will be
58
+ passed to a function as multiple arguments. In this case, the argument
59
+ should simply be `${foo}`:
60
+ ```cmake
61
+ vcpkg_list(SET working_directory)
62
+ if(DEFINED "arg_WORKING_DIRECTORY")
63
+ vcpkg_list(SET working_directory WORKING_DIRECTORY "${arg_WORKING_DIRECTORY}")
64
+ endif()
65
+ # calls do_the_thing() if NOT DEFINED arg_WORKING_DIRECTORY,
66
+ # else calls do_the_thing(WORKING_DIRECTORY "${arg_WORKING_DIRECTORY}")
67
+ do_the_thing(${working_directory})
68
+ ```
69
+ - Otherwise, if the argument contains any escape sequences that are not
70
+ `\\`, `\"`, or `\$`, that argument must be a quoted argument.
71
+ - For example: `"foo\nbar"` must be quoted.
72
+ - Otherwise, if the argument contains a `\`, a `"`, or a `$`,
73
+ that argument should be bracketed.
74
+ - Example:
75
+ ```cmake
76
+ set(x [[foo\bar]])
77
+ set(y [=[foo([[bar\baz]])]=])
78
+ ```
79
+ - Otherwise, if the argument contains characters that are
80
+ not alphanumeric or `_`, that argument should be quoted.
81
+ - Otherwise, the argument should be unquoted.
82
+ - Exception: arguments to `if()` of type `<variable|string>` should always be quoted:
83
+ - Both arguments to the comparison operators -
84
+ `EQUAL`, `STREQUAL`, `VERSION_LESS`, etc.
85
+ - The first argument to `MATCHES` and `IN_LIST`
86
+ - Example:
87
+ ```cmake
88
+ if("${FOO}" STREQUAL "BAR") # ...
89
+ if("${BAZ}" EQUAL "0") # ...
90
+ if("FOO" IN_LIST list_variable) # ...
91
+ if("${bar}" MATCHES [[a[bcd]+\.[bcd]+]]) # ...
92
+ ```
93
+ - For single expressions and for other types of predicates that do not
94
+ take `<variable|string>`, use the normal rules.
95
+ - There are no "pointer" or "in-out" parameters
96
+ (where a user passes a variable name rather than the contents),
97
+ except for simple out-parameters.
98
+ - Variables are not assumed to be empty.
99
+ If the variable is intended to be used locally,
100
+ it must be explicitly initialized to empty with `set(foo "")` if it is a string variable,
101
+ and `vcpkg_list(SET foo)` if it is a list variable.
102
+ - `set(var)` should not be used. Use `unset(var)` to unset a variable,
103
+ `set(var "")` to set it to the empty string,
104
+ and `vcpkg_list(SET var)` to set it to the empty list.
105
+ _Note: the empty string and the empty list are the same value;_
106
+ _this is a notational difference rather than a difference in result_
107
+ - All variables expected to be inherited from the parent scope across an API boundary
108
+ (i.e. not a file-local function) should be documented.
109
+ Note that all variables mentioned in triplets.md are considered documented.
110
+ - Out parameters are only set in `PARENT_SCOPE` and are never read.
111
+ See also the helper `z_vcpkg_forward_output_variable()` to forward out parameters through a function scope.
112
+ - `CACHE` variables are used only for global variables which are shared internally among strongly coupled
113
+ functions and for internal state within a single function to avoid duplicating work.
114
+ These should be used extremely sparingly and should use the `Z_VCPKG_` prefix to avoid
115
+ colliding with any local variables that would be defined by any other code.
116
+ - Examples:
117
+ - `vcpkg_cmake_configure`'s `Z_VCPKG_CMAKE_GENERATOR`
118
+ - `z_vcpkg_get_cmake_vars`'s `Z_VCPKG_GET_CMAKE_VARS_FILE`
119
+ - `include()`s are only allowed in `ports.cmake` or `vcpkg-port-config.cmake`.
120
+ - `foreach(RANGE)`'s arguments _must always be_ natural numbers,
121
+ and `<start>` _must always be_ less than or equal to `<stop>`.
122
+ - This must be checked by something like:
123
+ ```cmake
124
+ if("${start}" LESS_EQUAL "${end}")
125
+ foreach(RANGE "${start}" "${end}")
126
+ ...
127
+ endforeach()
128
+ endif()
129
+ ```
130
+ - All port-based scripts must use `include_guard(GLOBAL)`
131
+ to avoid being included multiple times.
132
+
133
+ ### CMake Versions to Require
134
+
135
+ - All CMake scripts, except for `vcpkg.cmake`,
136
+ may assume the version of CMake that is present in the
137
+ `cmake_minimum_required` of `ports.cmake`.
138
+ - This `cmake_minimum_required` should be bumped every time a new version
139
+ of CMake is added to `vcpkgTools.xml`, as should the
140
+ `cmake_minimum_required` in all of the helper `CMakeLists.txt` files.
141
+ - `vcpkg.cmake` must assume a version of CMake back to 3.7.2 in general
142
+ - Specific functions and options may assume a greater CMake version;
143
+ if they do, make sure to comment that function or option
144
+ with the required CMake version.
145
+
146
+
147
+ ### Changing Existing Functions
148
+
149
+ - Never remove arguments in non-internal functions;
150
+ if they should no longer do anything, just take them as normal and warn on use.
151
+ - Never add a new mandatory argument.
152
+
153
+ ### Naming Variables
154
+
155
+ - `cmake_parse_arguments`: set prefix to `"arg"`
156
+ - Local variables are named with `snake_case`
157
+ - Internal global variable names are prefixed with `Z_VCPKG_`.
158
+ - External experimental global variable names are prefixed with `X_VCPKG_`.
159
+
160
+ - Internal functions are prefixed with `z_vcpkg_`
161
+ - Functions which are internal to a single function (i.e., helper functions)
162
+ are named `[z_]<func>_<name>`, where `<func>` is the name of the function they are
163
+ a helper to, and `<name>` is what the helper function does.
164
+ - `z_` should be added to the front if `<func>` doesn't have a `z_`,
165
+ but don't name a helper function `z_z_foo_bar`.
166
+ - Public global variables are named `VCPKG_`.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/control-files.md ADDED
@@ -0,0 +1,205 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # CONTROL files
2
+
3
+ **CONTROL files are retained for backwards compatibility with earlier versions of vcpkg;
4
+ all new features are added only to [vcpkg.json manifest files](manifest-files.md), and we recommend using vcpkg.json for any newly authored port.
5
+ Use `./vcpkg format-manifest ports/<portname>/CONTROL` to convert an existing CONTROL file to a vcpkg.json file.**
6
+
7
+ The `CONTROL` file contains metadata about the port. The syntax is based on [the Debian `control` format][debian] although we only support the subset of fields documented here.
8
+
9
+ Field names are case-sensitive and start the line without leading whitespace. Paragraphs are separated by one or more empty lines.
10
+
11
+ [debian]: https://www.debian.org/doc/debian-policy/ch-controlfields.html
12
+
13
+ ## Source Paragraph
14
+
15
+ The first paragraph in a `CONTROL` file is the Source paragraph. It must have a `Source`, `Version`, and `Description` field. The full set of fields is documented below.
16
+
17
+ ### Examples:
18
+ ```no-highlight
19
+ Source: ace
20
+ Version: 6.5.5
21
+ Description: The ADAPTIVE Communication Environment
22
+ ```
23
+
24
+ ```no-highlight
25
+ Source: vtk
26
+ Version: 8.2.0
27
+ Port-Version: 2
28
+ Description: Software system for 3D computer graphics, image processing, and visualization
29
+ Build-Depends: zlib, libpng, tiff, libxml2, jsoncpp, glew, freetype, expat, hdf5, libjpeg-turbo, proj4, lz4, libtheora, atlmfc (windows), eigen3, double-conversion, pugixml, libharu, sqlite3, netcdf-c
30
+ ```
31
+
32
+
33
+ ### Recognized fields
34
+
35
+ #### Source
36
+ The name of the port.
37
+
38
+ When adding new ports be aware that the name may conflict with other projects that are not a part of vcpkg. For example `json` conflicts with too many other projects so you should add a scope to the name such as `taocpp-json` to make it unique. Verify there are no conflicts on a search engine as well as on other package collections.
39
+
40
+ Package collections to check for conflicts:
41
+
42
+ + [Repology](https://repology.org/projects/)
43
+ + [Debian packages](https://www.debian.org/distrib/packages)
44
+ + [Packages search](https://pkgs.org/)
45
+
46
+ #### Version
47
+ The library version.
48
+
49
+ This field is an alphanumeric string that may also contain `.`, `_`, or `-`. No attempt at ordering versions is made; all versions are treated as bit strings and are only evaluated for equality.
50
+
51
+ For tagged-release ports, we follow the following convention:
52
+
53
+ 1. If the port follows a scheme like `va.b.c`, we remove the leading `v`. In this case, it becomes `a.b.c`.
54
+ 2. If the port includes its own name in the version like `curl-7_65_1`, we remove the leading name: `7_65_1`
55
+
56
+ For rolling-release ports, we use the date that the _commit was accessed by you_, formatted as `YYYY-MM-DD`. Stated another way: if someone had a time machine and went to that date, they would see this commit as the latest master.
57
+
58
+ For example, given:
59
+ 1. The latest commit was made on 2019-04-19
60
+ 2. The current version string is `2019-02-14-1`
61
+ 3. Today's date is 2019-06-01.
62
+
63
+ Then if you update the source version today, you should give it version `2019-06-01`.
64
+
65
+ #### Port-Version
66
+ The version of the port.
67
+
68
+ This field is a non-negative integer. It allows one to version the port file separately from the version of the underlying library; if you make a change to a port, without changing the underlying version of the library, you should increment this field by one (starting at `0`, which is equivalent to no `Port-Version` field). When the version of the underlying library is upgraded, this field should be set back to `0` (i.e., delete the `Port-Version` field).
69
+
70
+ ##### Examples:
71
+ ```no-highlight
72
+ Version: 1.0.5
73
+ Port-Version: 2
74
+ ```
75
+ ```no-highlight
76
+ Version: 2019-03-21
77
+ ```
78
+
79
+ #### Description
80
+ A description of the library.
81
+
82
+ By convention the first line of the description is a summary of the library. An optional detailed description follows. The detailed description can be multiple lines, all starting with whitespace.
83
+
84
+ ##### Examples:
85
+ ```no-highlight
86
+ Description: C++ header-only JSON library
87
+ ```
88
+ ```no-highlight
89
+ Description: Mosquitto is an open source message broker that implements the MQ Telemetry Transport protocol versions 3.1 and 3.1.1.
90
+ MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for "machine
91
+ to machine" messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers like the Arduino.
92
+ ```
93
+
94
+ #### Homepage
95
+ The URL of the homepage for the library where a user is able to find additional documentation or the original source code.
96
+
97
+ Example:
98
+ ```no-highlight
99
+ Homepage: https://github.com/Microsoft/vcpkg
100
+ ```
101
+
102
+ #### Build-Depends
103
+ Comma separated list of vcpkg ports the library has a dependency on.
104
+
105
+ Vcpkg does not distinguish between build-only dependencies and runtime dependencies. The complete list of dependencies needed to successfully use the library should be specified.
106
+
107
+ *For example: websocketpp is a header only library, and thus does not require any dependencies at install time. However, downstream users need boost and openssl to make use of the library. Therefore, websocketpp lists boost and openssl as dependencies*
108
+
109
+ If the port is dependent on optional features of another library those can be specified using the `portname[featurelist]` syntax. If the port does not require any features from the dependency, this should be specified as `portname[core]`.
110
+
111
+ Dependencies can be filtered based on the target triplet to support differing requirements. These filters use the same syntax as the Supports field below and are surrounded in parentheses following the portname and feature list.
112
+
113
+ ##### Example:
114
+ ```no-highlight
115
+ Build-Depends: rapidjson, curl[core,openssl] (!windows), curl[core,winssl] (windows)
116
+ ```
117
+
118
+ #### Default-Features
119
+ Comma separated list of optional port features to install by default.
120
+
121
+ This field is optional.
122
+
123
+ ##### Example:
124
+ ```no-highlight
125
+ Default-Features: dynamodb, s3, kinesis
126
+ ```
127
+
128
+ <a name="Supports"></a>
129
+ #### Supports
130
+ Expression that evaluates to true when the port is expected to build successfully for a triplet.
131
+
132
+ Currently, this field is only used in the CI testing to skip ports. In the future, this mechanism is intended to warn users in advance that a given install tree is not expected to succeed. Therefore, this field should be used optimistically; in cases where a port is expected to succeed 10% of the time, it should still be marked "supported".
133
+
134
+ The grammar for the supports expression uses standard operators:
135
+ - `!expr` - negation
136
+ - `expr|expr` - or (`||` is also supported)
137
+ - `expr&expr` - and (`&&` is also supported)
138
+ - `(expr)` - grouping/precedence
139
+
140
+ The predefined expressions are computed from standard triplet settings:
141
+ - `native` - `TARGET_TRIPLET` == `HOST_TRIPLET`
142
+ - `x64` - `VCPKG_TARGET_ARCHITECTURE` == `"x64"`
143
+ - `x86` - `VCPKG_TARGET_ARCHITECTURE` == `"x86"`
144
+ - `arm` - `VCPKG_TARGET_ARCHITECTURE` == `"arm"` or `VCPKG_TARGET_ARCHITECTURE` == `"arm64"`
145
+ - `arm64` - `VCPKG_TARGET_ARCHITECTURE` == `"arm64"`
146
+ - `windows` - `VCPKG_CMAKE_SYSTEM_NAME` == `""` or `VCPKG_CMAKE_SYSTEM_NAME` == `"WindowsStore"`
147
+ - `uwp` - `VCPKG_CMAKE_SYSTEM_NAME` == `"WindowsStore"`
148
+ - `linux` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Linux"`
149
+ - `osx` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Darwin"`
150
+ - `android` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Android"`
151
+ - `static` - `VCPKG_LIBRARY_LINKAGE` == `"static"`
152
+ - `wasm32` - `VCPKG_TARGET_ARCHITECTURE` == `"wasm32"`
153
+ - `emscripten` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Emscripten"`
154
+
155
+ These predefined expressions can be overridden in the triplet file via the [`VCPKG_DEP_INFO_OVERRIDE_VARS`](../users/triplets.md) option.
156
+
157
+ This field is optional and defaults to true.
158
+
159
+ > Implementers' Note: these terms are computed from the triplet via the `vcpkg_get_dep_info` mechanism.
160
+
161
+ ##### Example:
162
+ ```no-highlight
163
+ Supports: !(uwp|arm)
164
+ ```
165
+
166
+ ## Feature Paragraphs
167
+
168
+ Multiple optional features can be specified in the `CONTROL` files. It must have a `Feature` and `Description` field. It can optionally have a `Build-Depends` field. It must be separated from other paragraphs by one or more empty lines.
169
+
170
+ ### Example:
171
+ ```no-highlight
172
+ Source: vtk
173
+ Version: 8.2.0-2
174
+ Description: Software system for 3D computer graphics, image processing, and visualization
175
+ Build-Depends: zlib, libpng, tiff, libxml2, jsoncpp, glew, freetype, expat, hdf5, libjpeg-turbo, proj4, lz4, libtheora, atlmfc (windows), eigen3, double-conversion, pugixml, libharu, sqlite3, netcdf-c
176
+
177
+ Feature: openvr
178
+ Description: OpenVR functionality for VTK
179
+ Build-Depends: sdl2, openvr
180
+
181
+ Feature: qt
182
+ Description: Qt functionality for VTK
183
+ Build-Depends: qt5
184
+
185
+ Feature: mpi
186
+ Description: MPI functionality for VTK
187
+ Build-Depends: mpi, hdf5[parallel]
188
+
189
+ Feature: python
190
+ Description: Python functionality for VTK
191
+ Build-Depends: python3
192
+ ```
193
+
194
+ ### Recognized fields
195
+
196
+ #### Feature
197
+ The name of the feature.
198
+
199
+ #### Description
200
+ A description of the feature using the same syntax as the port `Description` field.
201
+
202
+ #### Build-Depends
203
+ The list of dependencies required to build and use this feature.
204
+
205
+ On installation the dependencies from all selected features are combined to produce the full dependency list for the build. This field follows the same syntax as `Build-Depends` in the Source Paragraph.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/execute_process.md ADDED
@@ -0,0 +1,11 @@
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # execute_process
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/execute_process.md).
4
+
5
+ Intercepts all calls to execute_process() inside portfiles and fails when Download Mode
6
+ is enabled.
7
+
8
+ In order to execute a process in Download Mode call `vcpkg_execute_in_download_mode()` instead.
9
+
10
+ ## Source
11
+ [scripts/cmake/execute\_process.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/execute_process.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_apply_patches.md ADDED
@@ -0,0 +1,32 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # z_vcpkg_apply_patches
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/).
4
+
5
+ **Only for internal use in vcpkg helpers. Behavior and arguments will change without notice.**
6
+
7
+ Apply a set of patches to a source tree.
8
+
9
+ ```cmake
10
+ z_vcpkg_apply_patches(
11
+ SOURCE_PATH <path-to-source>
12
+ [QUIET]
13
+ PATCHES <patch>...
14
+ )
15
+ ```
16
+
17
+ The `<path-to-source>` should be set to `${SOURCE_PATH}` by convention,
18
+ and is the path to apply the patches in.
19
+
20
+ `z_vcpkg_apply_patches` will take the list of `<patch>`es,
21
+ which are by default relative to the port directory,
22
+ and apply them in order using `git apply`.
23
+ Generally, these `<patch>`es take the form of `some.patch`
24
+ to select patches in the port directory.
25
+ One may also download patches and use `${VCPKG_DOWNLOADS}/path/to/some.patch`.
26
+
27
+ If `QUIET` is not passed, it is a fatal error for a patch to fail to apply;
28
+ otherwise, if `QUIET` is passed, no message is printed.
29
+ This should only be used for edge cases, such as patches that are known to fail even on a clean source tree.
30
+
31
+ ## Source
32
+ [scripts/cmake/z\_vcpkg\_apply\_patches.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/z_vcpkg_apply_patches.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_forward_output_variable.md ADDED
@@ -0,0 +1,38 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # z_vcpkg_forward_output_variable
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/).
4
+
5
+ This macro helps with forwarding values from inner function calls,
6
+ through a local function scope, into pointer out parameters.
7
+
8
+ ```cmake
9
+ z_vcpkg_forward_output_variable(ptr_to_parent_var var_to_forward)
10
+ ```
11
+
12
+ is equivalent to
13
+
14
+ ```cmake
15
+ if(DEFINED ptr_to_parent_var)
16
+ if(DEFINED value_var)
17
+ set("${ptr_to_parent_var}" "${value_var}" PARENT_SCOPE)
18
+ else()
19
+ unset("${ptr_to_parent_var}" PARENT_SCOPE)
20
+ endif()
21
+ endif()
22
+ ```
23
+
24
+ Take note that the first argument should be a local variable that has a value of the parent variable name.
25
+ Most commonly, this local is the result of a pointer-out parameter to a function.
26
+ If the variable in the first parameter is not defined, this function does nothing,
27
+ simplifying functions with optional out parameters.
28
+ Most commonly, this should be used in cases like:
29
+
30
+ ```cmake
31
+ function(my_function out_var)
32
+ file(SHA512 "somefile.txt" local_var)
33
+ z_vcpkg_forward_output_variable(out_var local_var)
34
+ endfunction()
35
+ ```
36
+
37
+ ## Source
38
+ [scripts/cmake/z\_vcpkg\_forward\_output\_variable.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/z_vcpkg_forward_output_variable.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_function_arguments.md ADDED
@@ -0,0 +1,29 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # z_vcpkg_function_arguments
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/).
4
+
5
+ **Only for internal use in vcpkg helpers. Behavior and arguments will change without notice.**
6
+ Get a list of the arguments which were passed in.
7
+ Unlike `ARGV`, which is simply the arguments joined with `;`,
8
+ so that `(A B)` is not distinguishable from `("A;B")`,
9
+ this macro gives `"A;B"` for the first argument list,
10
+ and `"A\;B"` for the second.
11
+
12
+ ```cmake
13
+ z_vcpkg_function_arguments(<out-var> [<N>])
14
+ ```
15
+
16
+ `z_vcpkg_function_arguments` gets the arguments between `ARGV<N>` and the last argument.
17
+ `<N>` defaults to `0`, so that all arguments are taken.
18
+
19
+ ## Example:
20
+ ```cmake
21
+ function(foo_replacement)
22
+ z_vcpkg_function_arguments(ARGS)
23
+ foo(${ARGS})
24
+ ...
25
+ endfunction()
26
+ ```
27
+
28
+ ## Source
29
+ [scripts/cmake/z\_vcpkg\_function\_arguments.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/z_vcpkg_function_arguments.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_get_cmake_vars.md ADDED
@@ -0,0 +1,36 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # z_vcpkg_get_cmake_vars
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/).
4
+
5
+ **Only for internal use in vcpkg helpers. Behavior and arguments will change without notice.**
6
+ Runs a cmake configure with a dummy project to extract certain cmake variables
7
+
8
+ ## Usage
9
+ ```cmake
10
+ z_vcpkg_get_cmake_vars(<out-var>)
11
+ ```
12
+
13
+ `z_vcpkg_get_cmake_vars(cmake_vars_file)` sets `<out-var>` to
14
+ a path to a generated CMake file, with the detected `CMAKE_*` variables
15
+ re-exported as `VCPKG_DETECTED_*`.
16
+
17
+ ## Notes
18
+ Avoid usage in portfiles.
19
+
20
+ All calls to `z_vcpkg_get_cmake_vars` will result in the same output file;
21
+ the output file is not generated multiple times.
22
+
23
+ ## Examples
24
+
25
+ * [vcpkg_configure_make](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_configure_make.cmake)
26
+
27
+ ### Basic Usage
28
+
29
+ ```cmake
30
+ z_vcpkg_get_cmake_vars(cmake_vars_file)
31
+ include("${cmake_vars_file}")
32
+ message(STATUS "detected CXX flags: ${VCPKG_DETECTED_CXX_FLAGS}")
33
+ ```
34
+
35
+ ## Source
36
+ [scripts/cmake/z\_vcpkg\_get\_cmake\_vars.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/z_vcpkg_get_cmake_vars.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/internal/z_vcpkg_prettify_command_line.md ADDED
@@ -0,0 +1,21 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # z_vcpkg_prettify_command_line
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/).
4
+
5
+ **Only for internal use in vcpkg helpers. Behavior and arguments will change without notice.**
6
+ Turn a command line into a formatted string.
7
+
8
+ ```cmake
9
+ z_vcpkg_prettify_command_line(<out-var> <argument>...)
10
+ ```
11
+
12
+ This command is for internal use, when printing out to a message.
13
+
14
+ ## Examples
15
+
16
+ * `scripts/cmake/vcpkg_execute_build_process.cmake`
17
+ * `scripts/cmake/vcpkg_execute_required_process.cmake`
18
+ * `scripts/cmake/vcpkg_execute_required_process_repeat.cmake`
19
+
20
+ ## Source
21
+ [scripts/cmake/z\_vcpkg\_prettify\_command\_line.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/z_vcpkg_prettify_command_line.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/maintainer-guide.md ADDED
@@ -0,0 +1,418 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Maintainer Guidelines and Policies
2
+
3
+ This document lists a set of policies that you should apply when adding or updating a port recipe.
4
+ It is intended to serve the role of
5
+ [Debian's Policy Manual](https://www.debian.org/doc/debian-policy/),
6
+ [Homebrew's Maintainer Guidelines](https://docs.brew.sh/Maintainer-Guidelines), and
7
+ [Homebrew's Formula Cookbook](https://docs.brew.sh/Formula-Cookbook).
8
+
9
+ ## PR Structure
10
+
11
+ ### Make separate Pull Requests per port
12
+
13
+ Whenever possible, separate changes into multiple PRs.
14
+ This makes them significantly easier to review and prevents issues with one set of changes from holding up every other change.
15
+
16
+ ### Avoid trivial changes in untouched files
17
+
18
+ For example, avoid reformatting or renaming variables in portfiles that otherwise have no reason to be modified for the issue at hand.
19
+ However, if you need to modify the file for the primary purpose of the PR (updating the library),
20
+ then obviously beneficial changes like fixing typos are appreciated!
21
+
22
+ ### Check names against other repositories
23
+
24
+ A good service to check many at once is [Repology](https://repology.org/).
25
+ If the library you are adding could be confused with another one,
26
+ consider renaming to make it clear. We prefer when names are longer and/or
27
+ unlikely to conflict with any future use of the same name. If the port refers
28
+ to a library on GitHub, a good practice is to prefix the name with the organization
29
+ if there is any chance of confusion.
30
+
31
+ ### Use GitHub Draft PRs
32
+
33
+ GitHub Draft PRs are a great way to get CI or human feedback on work that isn't yet ready to merge.
34
+ Most new PRs should be opened as drafts and converted to normal PRs once the CI passes.
35
+
36
+ More information about GitHub Draft PRs:
37
+ https://github.blog/2019-02-14-introducing-draft-pull-requests/
38
+
39
+ ## Portfiles
40
+
41
+ ### Avoid deprecated helper functions
42
+
43
+ At this time, the following helpers are deprecated:
44
+
45
+ 1. `vcpkg_extract_source_archive()` should be replaced by [`vcpkg_extract_source_archive_ex()`](vcpkg_extract_source_archive_ex.md)
46
+ 2. `vcpkg_apply_patches()` should be replaced by the `PATCHES` arguments to the "extract" helpers (e.g. [`vcpkg_from_github()`](vcpkg_from_github.md))
47
+ 3. `vcpkg_build_msbuild()` should be replaced by [`vcpkg_install_msbuild()`](vcpkg_install_msbuild.md)
48
+ 4. `vcpkg_copy_tool_dependencies()` should be replaced by [`vcpkg_copy_tools()`](vcpkg_copy_tools.md)
49
+ 5. `vcpkg_configure_cmake` should be replaced by [`vcpkg_cmake_configure()`](ports/vcpkg-cmake/vcpkg_cmake_configure.md#vcpkg_cmake_configure) after removing `PREFER_NINJA` (from port [`vcpkg-cmake`](ports/vcpkg-cmake.md#vcpkg-cmake))
50
+ 6. `vcpkg_build_cmake` should be replaced by [`vcpkg_cmake_build()`](ports/vcpkg-cmake/vcpkg_cmake_build.md#vcpkg_cmake_build) (from port [`vcpkg-cmake`](ports/vcpkg-cmake.md#vcpkg-cmake))
51
+ 7. `vcpkg_install_cmake` should be replaced by [`vcpkg_cmake_install()`](ports/vcpkg-cmake/vcpkg_cmake_install.md#vcpkg_cmake_install) (from port [`vcpkg-cmake`](ports/vcpkg-cmake.md#vcpkg-cmake))
52
+ 8. `vcpkg_fixup_cmake_targets` should be replaced by [`vcpkg_cmake_config_fixup`](ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md#vcpkg_cmake_config_fixup) (from port [`vcpkg-cmake-config`](ports/vcpkg-cmake-config.md#vcpkg-cmake-config))
53
+
54
+ Some of the replacement helper functions are in "tools ports" to allow consumers to pin their
55
+ behavior at specific versions, to allow locking the behavior of the helpers at a particular
56
+ version. Tools ports need to be added to your port's `"dependencies"`, like so:
57
+
58
+ ```json
59
+ {
60
+ "name": "vcpkg-cmake",
61
+ "host": true
62
+ },
63
+ {
64
+ "name": "vcpkg-cmake-config",
65
+ "host": true
66
+ }
67
+ ```
68
+
69
+ ### Avoid excessive comments in portfiles
70
+
71
+ Ideally, portfiles should be short, simple, and as declarative as possible.
72
+ Remove any boiler plate comments introduced by the `create` command before submitting a PR.
73
+
74
+ ### Ports must not be path dependent
75
+
76
+ Ports must not change their behavior based on which ports are already installed in a form that would change which contents that port installs. For example, given:
77
+
78
+ ```
79
+ > vcpkg install a
80
+ > vcpkg install b
81
+ > vcpkg remove a
82
+ ```
83
+
84
+ and
85
+
86
+ ```
87
+ > vcpkg install b
88
+ ```
89
+
90
+ the files installed by `b` must be the same, regardless of influence by the previous installation of `a`. This means that ports must not try to detect whether something is provided in the installed tree by another port before taking some action. A specific and common cause of such "path dependent" behavior is described below in "When defining features, explicitly control dependencies."
91
+
92
+ ### Unique port attribution rule
93
+
94
+ In the entire vcpkg system, no two ports a user is expected to use concurrently may provide the same file. If a port tries to install a file already provided by another file, installation will fail. If a port wants to use an extremely common name for a header, for example, it should place those headers in a subdirectory rather than in `include`.
95
+
96
+ ### Add CMake exports in an unofficial- namespace
97
+
98
+ A core design ideal of vcpkg is to not create "lock-in" for customers. In the build system, there should be no difference between depending on a library from the system, and depending on a library from vcpkg. To that end, we avoid adding CMake exports or targets to existing libraries with "the obvious name", to allow upstreams to add their own official CMake exports without conflicting with vcpkg.
99
+
100
+ To that end, any CMake configs that the port exports, which are not in the upstream library, should have `unofficial-` as a prefix. Any additional targets should be in the `unofficial::<port>::` namespace.
101
+
102
+ This means that the user should see:
103
+ * `find_package(unofficial-<port> CONFIG)` as the way to get at the unique-to-vcpkg package
104
+ * `unofficial::<port>::<target>` as an exported target from that port.
105
+
106
+ Examples:
107
+ * [`brotli`](https://github.com/microsoft/vcpkg/blob/4f0a640e4c5b74166b759a862d7527c930eff32e/ports/brotli/install.patch) creates the `unofficial-brotli` package, producing target `unofficial::brotli::brotli`.
108
+
109
+ ## Features
110
+
111
+ ### Do not use features to implement alternatives
112
+
113
+ Features must be treated as additive functionality. If port[featureA] installs and port[featureB] installs, then port[featureA,featureB] must install. Moreover, if a second port depends on [featureA] and a third port depends on [featureB], installing both the second and third ports should have their dependencies satisfied.
114
+
115
+ Libraries in this situation must choose one of the available options as expressed in vcpkg, and users who want a different setting must use overlay ports at this time.
116
+
117
+ Existing examples we would not accept today retained for backwards compatibility:
118
+ * `libgit2`, `libzip`, `open62541` all have features for selecting a TLS or crypto backend. Note that `curl` has different crypto backend options but allows selecting between them at runtime, meaning the above tenet is maintained.
119
+ * `darknet` has `opencv2`, `opencv3`, features to control which version of opencv to use for its dependencies.
120
+
121
+ ### A feature may engage preview or beta functionality
122
+
123
+ Notwithstanding the above, if there is a preview branch or similar where the preview functionality has a high probability of not disrupting the non-preview functionality (for example, no API removals), a feature is acceptable to model this setting.
124
+
125
+ Examples:
126
+ * The Azure SDKs (of the form `azure-Xxx`) have a `public-preview` feature.
127
+ * `imgui` has an `experimental-docking` feature which engages their preview docking branch which uses a merge commit attached to each of their public numbered releases.
128
+
129
+ ### Default features should enable behaviors, not APIs
130
+
131
+ If a consumer is depending directly upon a library, they can list out any desired features easily (`library[feature1,feature2]`). However, if a consumer _does not know_ they are using a library, they cannot list out those features. If that hidden library is like `libarchive` where features are adding additional compression algorithms (and thus behaviors) to an existing generic interface, default features offer a way to ensure a reasonably functional transitive library is built even if the final consumer doesn't name it directly.
132
+
133
+ If the feature adds additional APIs (or executables, or library binaries) and doesn't modify the behavior of existing APIs, it should be left off by default. This is because any consumer which might want to use those APIs can easily require it via their direct reference.
134
+
135
+ If in doubt, do not mark a feature as default.
136
+
137
+ ### Do not use features to control alternatives in published interfaces
138
+
139
+ If a consumer of a port depends on only the core functionality of that port, with high probability they must not be broken by turning on the feature. This is even more important when the alternative is not directly controlled by the consumer, but by compiler settings like `/std:c++17` / `-std=c++17`.
140
+
141
+ Existing examples we would not accept today retained for backwards compatibility:
142
+ * `redis-plus-plus[cxx17]` controls a polyfill but does not bake the setting into the installed tree.
143
+ * `ace[wchar]` changes all APIs to accept `const wchar_t*` rather than `const char*`.
144
+
145
+ ### A feature may replace polyfills with aliases provided that replacement is baked into the installed tree
146
+
147
+ Notwithstanding the above, ports may remove polyfills with a feature, as long as:
148
+ 1. Turning on the feature changes the polyfills to aliases of the polyfilled entity
149
+ 2. The state of the polyfill is baked into the installed headers, such that ABI mismatch "impossible" runtime errors are unlikely
150
+ 3. It is possible for a consumer of the port to write code which works in both modes, for example by using a typedef which is either polyfilled or not
151
+
152
+ Example:
153
+ * `abseil[cxx17]` changes `absl::string_view` to a replacement or `std::string_view`; the patch
154
+ https://github.com/microsoft/vcpkg/blob/981e65ce0ac1f6c86e5a5ded7824db8780173c76/ports/abseil/fix-cxx-standard.patch implements the baking requirement
155
+
156
+ ### Recommended solutions
157
+
158
+ If it's critical to expose the underlying alternatives, we recommend providing messages at build time to instruct the user on how to copy the port into a private overlay:
159
+ ```cmake
160
+ set(USING_DOG 0)
161
+ message(STATUS "This version of LibContosoFrobnicate uses the Kittens backend. To use the Dog backend instead, create an overlay port of this with USING_DOG set to 1 and the `kittens` dependency replaced with `dog`.")
162
+ message(STATUS "This recipe is at ${CMAKE_CURRENT_LIST_DIR}")
163
+ message(STATUS "See the overlay ports documentation at https://github.com/microsoft/vcpkg/blob/master/docs/specifications/ports-overlay.md")
164
+ ```
165
+
166
+ ## Build Techniques
167
+
168
+ ### Do not use vendored dependencies
169
+
170
+ Do not use embedded copies of libraries.
171
+ All dependencies should be split out and packaged separately so they can be updated and maintained.
172
+
173
+ ### Prefer using CMake
174
+
175
+ When multiple buildsystems are available, prefer using CMake.
176
+ Additionally, when appropriate, it can be easier and more maintainable to rewrite alternative buildsystems into CMake using `file(GLOB)` directives.
177
+
178
+ Examples: [abseil](../../ports/abseil/portfile.cmake)
179
+
180
+ ### Choose either static or shared binaries
181
+
182
+ By default, `vcpkg_cmake_configure()` will pass in the appropriate setting for `BUILD_SHARED_LIBS`,
183
+ however for libraries that don't respect that variable, you can switch on `VCPKG_LIBRARY_LINKAGE`:
184
+
185
+ ```cmake
186
+ string(COMPARE EQUAL "${VCPKG_LIBRARY_LINKAGE}" "static" KEYSTONE_BUILD_STATIC)
187
+ string(COMPARE EQUAL "${VCPKG_LIBRARY_LINKAGE}" "dynamic" KEYSTONE_BUILD_SHARED)
188
+
189
+ vcpkg_cmake_configure(
190
+ SOURCE_PATH ${SOURCE_PATH}
191
+ OPTIONS
192
+ -DKEYSTONE_BUILD_STATIC=${KEYSTONE_BUILD_STATIC}
193
+ -DKEYSTONE_BUILD_SHARED=${KEYSTONE_BUILD_SHARED}
194
+ )
195
+ ```
196
+
197
+ ### When defining features, explicitly control dependencies
198
+
199
+ When defining a feature that captures an optional dependency,
200
+ ensure that the dependency will not be used accidentally when the feature is not explicitly enabled.
201
+
202
+ ```cmake
203
+ set(CMAKE_DISABLE_FIND_PACKAGE_ZLIB ON)
204
+ set(CMAKE_REQUIRE_FIND_PACKAGE_ZLIB OFF)
205
+ if ("zlib" IN_LIST FEATURES)
206
+ set(CMAKE_DISABLE_FIND_PACKAGE_ZLIB OFF)
207
+ set(CMAKE_REQUIRE_FIND_PACKAGE_ZLIB ON)
208
+ endif()
209
+
210
+ vcpkg_cmake_configure(
211
+ SOURCE_PATH ${SOURCE_PATH}
212
+ OPTIONS
213
+ -DCMAKE_DISABLE_FIND_PACKAGE_ZLIB=${CMAKE_DISABLE_FIND_PACKAGE_ZLIB}
214
+ -DCMAKE_REQUIRE_FIND_PACKAGE_ZLIB=${CMAKE_REQUIRE_FIND_PACKAGE_ZLIB}
215
+ )
216
+ ```
217
+
218
+ The snippet below using `vcpkg_check_features()` is equivalent, [see the documentation](vcpkg_check_features.md).
219
+
220
+ ```cmake
221
+ vcpkg_check_features(OUT_FEATURE_OPTIONS FEATURE_OPTIONS
222
+ FEATURES
223
+ "zlib" CMAKE_REQUIRE_FIND_PACKAGE_ZLIB
224
+ INVERTED_FEATURES
225
+ "zlib" CMAKE_DISABLE_FIND_PACKAGE_ZLIB
226
+ )
227
+
228
+ vcpkg_cmake_configure(
229
+ SOURCE_PATH ${SOURCE_PATH}
230
+ OPTIONS
231
+ ${FEATURE_OPTIONS}
232
+ )
233
+ ```
234
+
235
+ Note that `ZLIB` in the above is case-sensitive. See the [CMAKE_DISABLE_FIND_PACKAGE_PackageName](https://cmake.org/cmake/help/v3.22/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName.html) and [CMAKE_REQUIRE_FIND_PACKAGE_PackageName](https://cmake.org/cmake/help/v3.22/variable/CMAKE_REQUIRE_FIND_PACKAGE_PackageName.html) documnetation for more details.
236
+
237
+ ### Place conflicting libs in a `manual-link` directory
238
+
239
+ A lib is considered conflicting if it does any of the following:
240
+ + Define `main`
241
+ + Define malloc
242
+ + Define symbols that are also declared in other libraries
243
+
244
+ Conflicting libs are typically by design and not considered a defect. Because some build systems link against everything in the lib directory, these should be moved into a subdirectory named `manual-link`.
245
+
246
+ ## Manifests and CONTROL files
247
+
248
+ When adding a new port, use the new manifest syntax for defining a port;
249
+ you may also change over to manifests when modifying an existing port.
250
+ You may do so easily by running the `vcpkg format-manifest` command, which will convert existing CONTROL
251
+ files into manifest files. Do not convert CONTROL files that have not been modified.
252
+
253
+ ## Versioning
254
+
255
+ ### Follow common conventions for the `"version"` field
256
+
257
+ See our [versioning documentation](../users/versioning.md#version-schemes) for a full explanation of our conventions.
258
+
259
+ ### Update the `"port-version"` field in the manifest file of any modified ports
260
+
261
+ Vcpkg uses this field to determine whether a given port is out-of-date and should be changed whenever the port's behavior changes.
262
+
263
+ Our convention is to use the `"port-version"` field for changes to the port that don't change the upstream version, and to reset the `"port-version"` back to zero when an update to the upstream version is made.
264
+
265
+ For Example:
266
+
267
+ - Zlib's package version is currently `1.2.1`, with no explicit `"port-version"` (equivalent to a `"port-version"` of `0`).
268
+ - You've discovered that the wrong copyright file has been deployed, and fixed that in the portfile.
269
+ - You should update the `"port-version"` field in the manifest file to `1`.
270
+
271
+ See our [manifest files document](manifest-files.md#port-version) for a full explanation of our conventions.
272
+
273
+ ### Update the version files in `versions/` of any modified ports
274
+
275
+ Vcpkg uses a set of metadata files to power its versioning feature.
276
+ These files are located in the following locations:
277
+ * `${VCPKG_ROOT}/versions/baseline.json`, (this file is common to all ports) and
278
+ * `${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json` (one per port).
279
+
280
+ For example, for `zlib` the relevant files are:
281
+ * `${VCPKG_ROOT}/versions/baseline.json`
282
+ * `${VCPKG_ROOT}/versions/z-/zlib.json`
283
+
284
+ We expect that each time you update a port, you also update its version files.
285
+
286
+ **The recommended method to update these files is to run the `x-add-version` command, e.g.:**
287
+
288
+ ```
289
+ vcpkg x-add-version zlib
290
+ ```
291
+
292
+ If you're updating multiple ports at the same time, instead you can run:
293
+
294
+ ```
295
+ vcpkg x-add-version --all
296
+ ```
297
+
298
+ To update the files for all modified ports at once.
299
+
300
+ _NOTE: These commands require you to have committed your changes to the ports before running them. The reason is that the Git SHA of the port directory is required in these version files. But don't worry, the `x-add-version` command will warn you if you have local changes that haven't been committed._
301
+
302
+ See our [versioning specification](../specifications/versioning.md) and [registries specification](../specifications/registries-2.md) to learn how vcpkg interacts with these files.
303
+
304
+ ## Patching
305
+
306
+ ### Prefer options over patching
307
+
308
+ It is preferable to set options in a call to `vcpkg_configure_xyz()` over patching the settings directly.
309
+
310
+ Common options that allow avoiding patching:
311
+ 1. [MSBUILD] `<PropertyGroup>` settings inside the project file can be overridden via `/p:` parameters
312
+ 2. [CMAKE] Calls to `find_package(XYz)` in CMake scripts can be disabled via [`-DCMAKE_DISABLE_FIND_PACKAGE_XYz=ON`](https://cmake.org/cmake/help/v3.15/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName.html)
313
+ 3. [CMAKE] Cache variables (declared as `set(VAR "value" CACHE STRING "Documentation")` or `option(VAR "Documentation" "Default Value")`) can be overridden by just passing them in on the command line as `-DVAR:STRING=Foo`. One notable exception is if the `FORCE` parameter is passed to `set()`. See also the [CMake `set` documentation](https://cmake.org/cmake/help/v3.15/command/set.html)
314
+
315
+ ### Prefer patching over overriding `VCPKG_<VARIABLE>` values
316
+
317
+ Some variables prefixed with `VCPKG_<VARIABLE>` have an equivalent `CMAKE_<VARIABLE>`.
318
+ However, not all of them are passed to the internal package build [(see implementation: Windows toolchain)](../../scripts/toolchains/windows.cmake).
319
+
320
+ Consider the following example:
321
+
322
+ ```cmake
323
+ set(VCPKG_C_FLAGS "-O2 ${VCPKG_C_FLAGS}")
324
+ set(VCPKG_CXX_FLAGS "-O2 ${VCPKG_CXX_FLAGS}")
325
+ ```
326
+
327
+ Using `vcpkg`'s built-in toolchains this works, because the value of `VCPKG_<LANG>_FLAGS` is forwarded to the appropriate `CMAKE_LANG_FLAGS` variable. But, a custom toolchain that is not aware of `vcpkg`'s variables will not forward them.
328
+
329
+ Because of this, it is preferable to patch the buildsystem directly when setting `CMAKE_<LANG>_FLAGS`.
330
+
331
+ ### Minimize patches
332
+
333
+ When making changes to a library, strive to minimize the final diff. This means you should _not_ reformat the upstream source code when making changes that affect a region. Also, when disabling a conditional, it is better to add a `AND FALSE` or `&& 0` to the condition than to delete every line of the conditional.
334
+
335
+ Don't add patches if the port is outdated and updating the port to a newer released version would solve the same issue. vcpkg prefers updating ports over patching outdated versions unless the version bump breaks a considerable amount of dependent ports.
336
+
337
+ This helps to keep the size of the vcpkg repository down as well as improves the likelihood that the patch will apply to future code versions.
338
+
339
+ ### Do not implement features in patches
340
+
341
+ The purpose of patching in vcpkg is to enable compatibility with compilers, libraries, and platforms. It is not to implement new features in lieu of following proper Open Source procedure (submitting an Issue/PR/etc).
342
+
343
+ ## Do not build tests/docs/examples by default
344
+
345
+ When submitting a new port, check for any options like `BUILD_TESTS` or `WITH_TESTS` or `POCO_ENABLE_SAMPLES` and ensure the additional binaries are disabled. This minimizes build times and dependencies for the average user.
346
+
347
+ Optionally, you can add a `test` feature which enables building the tests, however this should not be in the `Default-Features` list.
348
+
349
+ ## Enable existing users of the library to switch to vcpkg
350
+
351
+ ### Do not add `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS`
352
+
353
+ Unless the author of the library is already using it, we should not use this CMake functionality because it interacts poorly with C++ templates and breaks certain compiler features. Libraries that don't provide a .def file and do not use __declspec() declarations simply do not support shared builds for Windows and should be marked as such with `vcpkg_check_linkage(ONLY_STATIC_LIBRARY)`.
354
+
355
+ ### Do not rename binaries outside the names given by upstream
356
+
357
+ This means that if the upstream library has different names in release and debug (libx versus libxd), then the debug library should not be renamed to `libx`. Vice versa, if the upstream library has the same name in release and debug, we should not introduce a new name.
358
+
359
+ Important caveat:
360
+ - Static and shared variants often should be renamed to a common scheme. This enables consumers to use a common name and be ignorant of the downstream linkage. This is safe because we only make one at a time available.
361
+
362
+ Note that if a library generates CMake integration files (`foo-config.cmake`), renaming must be done through patching the CMake build itself instead of simply calling `file(RENAME)` on the output archives/LIBs.
363
+
364
+ Finally, DLL files on Windows should never be renamed post-build because it breaks the generated LIBs.
365
+
366
+ ## Code format
367
+
368
+ ### Vcpkg internal code
369
+
370
+ We require the C++ code inside vcpkg to follow the clang-format, if you change them. Please perform the following steps after modification:
371
+
372
+ - Use Visual Studio:
373
+ 1. Configure your [clang-format tools](https://devblogs.microsoft.com/cppblog/clangformat-support-in-visual-studio-2017-15-7-preview-1/).
374
+ 2. Open the modified file.
375
+ 3. Use shortcut keys Ctrl+K, Ctrl+D to format the current file.
376
+
377
+ - Use tools:
378
+ 1. Install [llvm clang-format](https://releases.llvm.org/download.html#10.0.0)
379
+ 2. Run command:
380
+ ```cmd
381
+ > LLVM_PATH/bin/clang-format.exe -style=file -i changed_file.cpp
382
+ ```
383
+
384
+ ### Manifests
385
+
386
+ We require that the manifest file be formatted. Use the following command to format all manifest files:
387
+
388
+ ```cmd
389
+ > vcpkg format-manifest --all
390
+ ```
391
+
392
+ ## Useful implementation notes
393
+
394
+ ### Portfiles are run in Script Mode
395
+
396
+ While `portfile.cmake`'s and `CMakeLists.txt`'s share a common syntax and core CMake language constructs, portfiles run in "Script Mode", whereas `CMakeLists.txt` files run in "Build Mode" (unofficial term). The most important difference between these two modes is that "Script Mode" does not have a concept of "Target" -- any behaviors that depend on the "target" machine (`CMAKE_CXX_COMPILER`, `CMAKE_EXECUTABLE_SUFFIX`, `CMAKE_SYSTEM_NAME`, etc) will not be correct.
397
+
398
+ Portfiles have direct access to variables set in the triplet file, but `CMakeLists.txt`s do not (though there is often a translation that happens -- `VCPKG_LIBRARY_LINKAGE` versus `BUILD_SHARED_LIBS`).
399
+
400
+ Portfiles and CMake builds invoked by portfiles are run in different processes. Conceptually:
401
+
402
+ ```no-highlight
403
+ +----------------------------+ +------------------------------------+
404
+ | CMake.exe | | CMake.exe |
405
+ +----------------------------+ +------------------------------------+
406
+ | Triplet file | ====> | Toolchain file |
407
+ | (x64-windows.cmake) | | (scripts/buildsystems/vcpkg.cmake) |
408
+ +----------------------------+ +------------------------------------+
409
+ | Portfile | ====> | CMakeLists.txt |
410
+ | (ports/foo/portfile.cmake) | | (buildtrees/../CMakeLists.txt) |
411
+ +----------------------------+ +------------------------------------+
412
+ ```
413
+
414
+ To determine the host in a portfile, the standard CMake variables are fine (`CMAKE_HOST_WIN32`).
415
+
416
+ To determine the target in a portfile, the vcpkg triplet variables should be used (`VCPKG_CMAKE_SYSTEM_NAME`).
417
+
418
+ See also our [triplet documentation](../users/triplets.md) for a full enumeration of possible settings.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/manifest-files.md ADDED
@@ -0,0 +1,551 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Manifest files - `vcpkg.json`
2
+
3
+ The `vcpkg.json` file contains metadata about the port.
4
+ It's a JSON file, and replaces the existing CONTROL file metadata structure.
5
+ It must have a top level object, and all fields are case sensitive.
6
+
7
+ ## Examples:
8
+
9
+ The most important fields in a manifest, the ones which are required for all ports,
10
+ are the `"name"` field, and a version field (for now, just `"version-string"`).
11
+ There's more information about these fields below.
12
+
13
+ ```json
14
+ {
15
+ "name": "ace",
16
+ "version-string": "6.5.5"
17
+ }
18
+ ```
19
+
20
+ ```json
21
+ {
22
+ "name": "vtk",
23
+ "version-string": "8.2.0",
24
+ "port-version": 2,
25
+ "description": "Software system for 3D computer graphics, image processing, and visualization",
26
+ "dependencies": [
27
+ {
28
+ "name": "atlmfc",
29
+ "platform": "windows"
30
+ },
31
+ "double-conversion",
32
+ "eigen3",
33
+ "expat",
34
+ "freetype",
35
+ "glew",
36
+ "hdf5",
37
+ "jsoncpp",
38
+ "libharu",
39
+ "libjpeg-turbo",
40
+ "libpng",
41
+ "libtheora",
42
+ "libxml2",
43
+ "lz4",
44
+ "netcdf-c",
45
+ "proj4",
46
+ "pugixml",
47
+ "sqlite3",
48
+ "tiff",
49
+ "zlib"
50
+ ]
51
+ }
52
+ ```
53
+
54
+ ## Fields
55
+
56
+ ### `"name"`
57
+ The name of the port.
58
+
59
+ When adding new ports be aware that the name may conflict with other projects that are not a part of vcpkg. For example `json` conflicts with too many other projects so you should add a scope to the name such as `taocpp-json` to make it unique. Verify there are no conflicts on a search engine as well as on other package collections.
60
+
61
+ Package collections to check for conflicts:
62
+
63
+ + [Repology](https://repology.org/projects/)
64
+ + [Debian packages](https://www.debian.org/distrib/packages)
65
+ + [Packages search](https://pkgs.org/)
66
+
67
+ A name must be an identifier: i.e., it must only consist of lowercase ascii alphabetic characters,
68
+ numbers, and hyphens, and it must not begin nor end with a hyphen.
69
+
70
+ ### Version fields
71
+
72
+ Currently there are different fields for special versioning. Namely:
73
+
74
+ Manifest property | Versioning scheme
75
+ ------------------|------------------------------------
76
+ `version` | For dot-separated numeric versions
77
+ `version-semver` | For SemVer compliant versions
78
+ `version-date` | For dates in the format YYYY-MM-DD
79
+ `version-string` | For arbitrary strings
80
+
81
+ See https://github.com/microsoft/vcpkg/blob/master/docs/specifications/versioning.md#22-package-versions for more details.
82
+
83
+ Additionally, `"port-version"` is used to differentiate between port changes that don't change the underlying library version.
84
+
85
+ #### `"version-string"`
86
+
87
+ This field is an ascii string, and may contain alphanumeric characters, `.`, `_`, or `-`. No attempt at ordering versions is made; all versions are treated as byte strings and are only evaluated for equality.
88
+
89
+ For tagged-release ports, we follow the following convention:
90
+
91
+ 1. If the library follows a scheme like `va.b.c`, we remove the leading `v`. In this case, it becomes `a.b.c`.
92
+ 2. If the library includes its own name in the version like `curl-7_65_1`, we remove the leading name: `7_65_1`
93
+ 3. If the library is versioned by dates, format the resulting version string just like the upstream library;
94
+ for example, Abseil formats their dates `lts_2020_02_25`, so the `"version-string"` should be `"lts_2020_02_25"`.
95
+
96
+ For rolling-release ports, we use the date that the _commit was accessed by you_, formatted as `YYYY-MM-DD`. Stated another way: if someone had a time machine and went to that date, they would see this commit as the latest master.
97
+
98
+ For example, given:
99
+ 1. The latest commit was made on 2019-04-19
100
+ 2. The current version string is `2019-02-14`
101
+ 3. Today's date is 2019-06-01.
102
+
103
+ Then if you update the source version today, you should give it version `2019-06-01`.
104
+
105
+ #### `"port-version"`
106
+
107
+ The version of the port, aside from the library version.
108
+
109
+ This field is a non-negative integer.
110
+ It allows one to version the port file separately from the version of the underlying library;
111
+ if you make a change to a port, without changing the underlying version of the library,
112
+ you should increment this field by one (starting at `0`, which is equivalent to no `"port-version"` field).
113
+ When the version of the underlying library is upgraded,
114
+ this field should be set back to `0` (i.e., delete the `"port-version"` field).
115
+
116
+ #### Examples:
117
+ ```json
118
+ {
119
+ "version": "1.0.5",
120
+ "port-version": 2
121
+ }
122
+ ```
123
+
124
+ ```json
125
+ {
126
+ "version": "2019-03-21"
127
+ }
128
+ ```
129
+
130
+ ### `"description"`
131
+
132
+ A description of the library.
133
+
134
+ This field can either be a single string, which should be a summary of the library,
135
+ or can be an array, with the first line being a summary and the remaining lines being the detailed description -
136
+ one string per line.
137
+
138
+ #### Examples:
139
+ ```json
140
+ {
141
+ "description": "C++ header-only JSON library"
142
+ }
143
+ ```
144
+ ```json
145
+ {
146
+ "description": [
147
+ "Mosquitto is an open source message broker that implements the MQ Telemetry Transport protocol versions 3.1 and 3.1.1.",
148
+ "MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model."
149
+ "This makes it suitable for 'machine to machine' messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers like the Arduino."
150
+ ]
151
+ }
152
+ ```
153
+
154
+ ### `"homepage"`
155
+
156
+ The URL of the homepage for the library where a user is able to find additional documentation or the original source code.
157
+
158
+ ### `"documentation"`
159
+
160
+ The URL where a user would be able to find official documentation for the library. Optional.
161
+
162
+ ### `"maintainers"`
163
+
164
+ A list of strings that define the set of maintainers of a package.
165
+ It's recommended that these take the form of `Givenname Surname <email>`,
166
+ but this field is not checked for consistency.
167
+
168
+ Optional.
169
+
170
+ #### Example:
171
+ ```json
172
+ {
173
+ "homepage": "https://github.com/microsoft/vcpkg"
174
+ }
175
+ ```
176
+
177
+ ### `"dependencies"`
178
+
179
+ An array of ports the library has a dependency on.
180
+
181
+ vcpkg does not distinguish between build-only dependencies and runtime dependencies.
182
+ The complete list of dependencies needed to successfully use the library should be specified.
183
+
184
+ For example: websocketpp is a header only library, and thus does not require any dependencies at install time.
185
+ However, downstream users need boost and openssl to make use of the library.
186
+ Therefore, websocketpp lists boost and openssl as dependencies.
187
+
188
+ Each dependency may be either an identifier, or an object.
189
+ For many dependencies, just listing the name of the library should be fine;
190
+ however, if one needs to add extra information to that dependency, one may use the dependency object.
191
+ For a dependency object, the `"name"` field is used to designate the library;
192
+ for example the dependency object `{ "name": "zlib" }` is equivalent to just writing `"zlib"`.
193
+
194
+ If the port is dependent on optional features of another library,
195
+ those can be specified using the `"features"` field of the dependency object.
196
+ If the port does not require any features from the dependency,
197
+ this should be specified with the `"default-features"` fields set to `false`.
198
+
199
+ Dependencies can also be filtered based on the target triplet to support differing requirements.
200
+ These filters use the same syntax as the `"supports"` field below,
201
+ and are specified in the `"platform"` field.
202
+
203
+ #### Example:
204
+ ```json
205
+ {
206
+ "dependencies": [
207
+ {
208
+ "name": "curl",
209
+ "default-features": false,
210
+ "features": [
211
+ "winssl"
212
+ ],
213
+ "platform": "windows"
214
+ },
215
+ {
216
+ "name": "curl",
217
+ "default-features": false,
218
+ "features": [
219
+ "openssl"
220
+ ],
221
+ "platform": "!windows"
222
+ },
223
+ "rapidjson"
224
+ ]
225
+ }
226
+ ```
227
+
228
+ ### `"features"`
229
+
230
+ Multiple optional features can be specified in manifest files, in the `"features"` object field.
231
+ This field is a map from the feature name, to the feature's information.
232
+ Each one must have a `"description"` field, and may also optionally have a `"dependencies"` field.
233
+
234
+ A feature's name must be an identifier -
235
+ in other words, lowercase alphabetic characters, digits, and hyphens,
236
+ neither starting nor ending with a hyphen.
237
+
238
+ A feature's `"description"` is a description of the feature,
239
+ and is the same kind of thing as the port `"description"` field.
240
+
241
+ A feature's `"dependencies"` field contains the list of extra dependencies required to build and use this feature;
242
+ this field isn't required if the feature doesn't require any extra dependencies.
243
+ On installation the dependencies from all selected features are combined to produce the full dependency list for the build.
244
+
245
+ #### Example:
246
+
247
+ ```json
248
+ {
249
+ "name": "vtk",
250
+ "version-string": "8.2.0",
251
+ "port-version": 2,
252
+ "description": "Software system for 3D computer graphics, image processing, and visualization",
253
+ "dependencies": [
254
+ {
255
+ "name": "atlmfc",
256
+ "platform": "windows"
257
+ },
258
+ "double-conversion",
259
+ "eigen3",
260
+ "expat",
261
+ "freetype",
262
+ "glew",
263
+ "hdf5",
264
+ "jsoncpp",
265
+ "libharu",
266
+ "libjpeg-turbo",
267
+ "libpng",
268
+ "libtheora",
269
+ "libxml2",
270
+ "lz4",
271
+ "netcdf-c",
272
+ "proj4",
273
+ "pugixml",
274
+ "sqlite3",
275
+ "tiff",
276
+ "zlib"
277
+ ],
278
+ "features": {
279
+ "mpi": {
280
+ "description": "MPI functionality for VTK",
281
+ "dependencies": [
282
+ {
283
+ "name": "hdf5",
284
+ "features": [
285
+ "parallel"
286
+ ]
287
+ },
288
+ "mpi"
289
+ ]
290
+ },
291
+ "openvr": {
292
+ "description": "OpenVR functionality for VTK",
293
+ "dependencies": [
294
+ "openvr",
295
+ "sdl2"
296
+ ]
297
+ },
298
+ "python": {
299
+ "description": "Python functionality for VTK",
300
+ "dependencies": [
301
+ "python3"
302
+ ]
303
+ },
304
+ "qt": {
305
+ "description": "Qt functionality for VTK",
306
+ "dependencies": [
307
+ "qt5"
308
+ ]
309
+ }
310
+ }
311
+ }
312
+ ```
313
+
314
+ ### `"default-features"`
315
+
316
+ An array of feature names that the library uses by default, if nothing else is specified.
317
+
318
+ #### Example:
319
+ ```json
320
+ {
321
+ "default-features": [
322
+ "kinesis"
323
+ ],
324
+ "features": {
325
+ "dynamodb": {
326
+ "description": "Build dynamodb support",
327
+ "dependencies": [
328
+ "dynamodb"
329
+ ]
330
+ },
331
+ "kinesis": {
332
+ "description": "build kinesis support"
333
+ }
334
+ }
335
+ }
336
+ ```
337
+
338
+ ### `"supports"`
339
+
340
+ A string, formatted as a platform expression,
341
+ that evaluates to true when the port should build successfully for a triplet.
342
+
343
+ This field is used in the CI testing to skip ports,
344
+ and warns users in advance that a given install tree is not expected to succeed.
345
+ Therefore, this field should be used optimistically;
346
+ in cases where a port is expected to succeed 10% of the time, it should still be marked "supported".
347
+
348
+ The grammar for this top-level platform expression, in [EBNF], is as follows:
349
+
350
+ ```ebnf
351
+ whitespace-character =
352
+ | ? U+0009 "CHARACTER TABULATION" ?
353
+ | ? U+000A "LINE FEED" ?
354
+ | ? U+000D "CARRIAGE RETURN" ?
355
+ | ? U+0020 "SPACE" ? ;
356
+ optional-whitespace = { whitespace-character } ;
357
+ required-whitespace = whitespace-character, { optional-whitespace } ;
358
+
359
+ lowercase-alpha =
360
+ | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m"
361
+ | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ;
362
+ digit =
363
+ | "0" | "1" | "2" | "3" | "4"
364
+ | "5" | "6" | "7" | "8" | "9" ;
365
+ identifier-character =
366
+ | lowercase-alpha
367
+ | digit ;
368
+
369
+ platform-expression-list =
370
+ | platform-expression { ",", optional-whitespace, platform-expression } ;
371
+
372
+ platform-expression =
373
+ | platform-expression-not
374
+ | platform-expression-and
375
+ | platform-expression-or ;
376
+
377
+ platform-expression-identifier =
378
+ | identifier-character, { identifier-character }, optional-whitespace ;
379
+
380
+ platform-expression-grouped =
381
+ | "(", optional-whitespace, platform-expression, ")", optional-whitespace ;
382
+
383
+ platform-expression-simple =
384
+ | platform-expression-identifier
385
+ | platform-expression-grouped ;
386
+
387
+ platform-expression-unary-keyword-operand =
388
+ | required-whitespace, platform-expression-simple
389
+ | optional-whitespace, platform-expression-grouped ;
390
+
391
+ platform-expression-not =
392
+ | platform-expression-simple
393
+ | "!", optional-whitespace, platform-expression-simple
394
+ | "not", platform-expression-unary-keyword-operand ;
395
+
396
+ platform-expression-binary-keyword-first-operand =
397
+ | platform-expression-not, required-whitespace
398
+ | platform-expression-grouped ;
399
+
400
+ platform-expression-binary-keyword-second-operand =
401
+ | required-whitespace, platform-expression-not
402
+ | platform-expression-grouped ;
403
+
404
+ platform-expression-and =
405
+ | platform-expression-not, { "&", optional-whitespace, platform-expression-not }
406
+ | platform-expression-binary-keyword-first-operand, { "and", platform-expression-binary-keyword-second-operand } ;
407
+
408
+ platform-expression-or =
409
+ | platform-expression-not, { "|", optional-whitespace, platform-expression-not }
410
+ | platform-expression-binary-keyword-first-operand, { "or", platform-expression-binary-keyword-second-operand } (* to allow for future extension *) ;
411
+
412
+ top-level-platform-expression = optional-whitespace, platform-expression-list ;
413
+ ```
414
+
415
+ Basically, there are four kinds of expressions -- identifiers, negations, ands, and ors.
416
+ Negations may only negate an identifier or a grouped expression.
417
+ Ands and ors are a list of `&` or `|` separated identifiers, negated expressions, and grouped expressions.
418
+ One may not mix `&` and `|` without parentheses for grouping.
419
+
420
+ These predefined identifier expressions are computed from standard triplet settings:
421
+ - `native` - `TARGET_TRIPLET` == `HOST_TRIPLET`;
422
+ useful for ports which depend on their own built binaries in their build.
423
+ - `x64` - `VCPKG_TARGET_ARCHITECTURE` == `"x64"`
424
+ - `x86` - `VCPKG_TARGET_ARCHITECTURE` == `"x86"`
425
+ - `arm` - `VCPKG_TARGET_ARCHITECTURE` == `"arm"` or `VCPKG_TARGET_ARCHITECTURE` == `"arm64"`
426
+ - `arm64` - `VCPKG_TARGET_ARCHITECTURE` == `"arm64"`
427
+ - `windows` - `VCPKG_CMAKE_SYSTEM_NAME` == `""` or `VCPKG_CMAKE_SYSTEM_NAME` == `"WindowsStore"`
428
+ - `mingw` - `VCPKG_CMAKE_SYSTEM_NAME` == `"MinGW"`
429
+ - `uwp` - `VCPKG_CMAKE_SYSTEM_NAME` == `"WindowsStore"`
430
+ - `linux` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Linux"`
431
+ - `osx` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Darwin"`
432
+ - `android` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Android"`
433
+ - `static` - `VCPKG_LIBRARY_LINKAGE` == `"static"`
434
+ - `wasm32` - `VCPKG_TARGET_ARCHITECTURE` == `"wasm32"`
435
+ - `emscripten` - `VCPKG_CMAKE_SYSTEM_NAME` == `"Emscripten"`
436
+ - `staticcrt` - `VCPKG_CRT_LINKAGE` == `"static"`
437
+
438
+ These predefined identifier expressions can be overridden in the triplet file,
439
+ via the [`VCPKG_DEP_INFO_OVERRIDE_VARS`](../users/triplets.md) option,
440
+ and new identifier expressions can be added via the same mechanism.
441
+
442
+ This field is optional and defaults to true.
443
+
444
+ > Implementers' Note: these terms are computed from the triplet via the `vcpkg_get_dep_info` mechanism.
445
+
446
+ [EBNF]: https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
447
+
448
+ #### Example:
449
+ ```json
450
+ {
451
+ "supports": "!uwp & !(arm & !arm64)"
452
+ }
453
+ ```
454
+
455
+ This means "doesn't support uwp, nor arm32 (but does support arm64)".
456
+
457
+ ### `"license"`
458
+
459
+ The license of the port. This is an [SPDX license expression],
460
+ or `null` for proprietary licenses and other licenses for which
461
+ one should "just read the `copyright` file" (e.g., Qt).
462
+
463
+ [SPDX license expression]: https://spdx.dev/ids/#how
464
+
465
+ Additionally, you can find the list of [recognized license IDs]
466
+ and [recognized license exception IDs] in Annex A of the SPDX specification.
467
+
468
+ [recognized license IDs]: https://spdx.github.io/spdx-spec/SPDX-license-list/#a1-licenses-with-short-identifiers
469
+ [recognized license exception IDs]: https://spdx.github.io/spdx-spec/SPDX-license-list/#a2-exceptions-list
470
+
471
+ The following is an EBNF conversion of the ABNF located at
472
+ <https://spdx.github.io/spdx-spec/SPDX-license-expressions/>,
473
+ and this is what we actually parse in vcpkg.
474
+ Note that vcpkg does not support DocumentRefs.
475
+
476
+ ```ebnf
477
+ idchar = ? regex /[-.a-zA-Z0-9]/ ?
478
+ idstring = ( idchar ), { idchar } ;
479
+
480
+ (* note that unrecognized license and license exception IDs will be warned against *)
481
+ license-id = idstring ;
482
+ license-exception-id = idstring ;
483
+ (* note that DocumentRefs are unsupported by this implementation *)
484
+ license-ref = "LicenseRef-", idstring ;
485
+
486
+ with = [ whitespace ], "WITH", [ whitespace ] ;
487
+ and = [ whitespace ], "AND", [ whitespace ] ;
488
+ or = [ whitespace ], "OR", [ whitespace ] ;
489
+
490
+ simple-expression = [ whitespace ], (
491
+ | license-id
492
+ | license-id, "+"
493
+ | license-ref
494
+ ), [ whitespace ] ;
495
+
496
+ (* the following are split up from compound-expression to make precedence obvious *)
497
+ parenthesized-expression =
498
+ | simple-expression
499
+ | [ whitespace ], "(", or-expression, ")", [ whitespace ] ;
500
+
501
+ with-expression =
502
+ | parenthesized-expression
503
+ | simple-expression, with, license-exception-id, [ whitespace ] ;
504
+
505
+ (* note: "a AND b OR c" gets parsed as "(a AND b) OR c" *)
506
+ and-expression = with-expression, { and, with-expression } ;
507
+ or-expression = and-expression, { or, and-exression } ;
508
+
509
+ license-expression = or-expression ;
510
+ ```
511
+
512
+ #### Examples
513
+
514
+ For libraries with simple licensing,
515
+ only one license identifier may be needed;
516
+
517
+ vcpkg, for example, would use this since it uses the MIT license:
518
+
519
+ ```json
520
+ {
521
+ "license": "MIT"
522
+ }
523
+ ```
524
+
525
+ Many GPL'd projects allow either the GPL 2 or any later versions:
526
+
527
+ ```json
528
+ {
529
+ "license": "GPL-2.0-or-later"
530
+ }
531
+ ```
532
+
533
+ Many Rust projects, in order to make certain they're useable with GPL,
534
+ but also desiring the MIT license, will allow licensing under either
535
+ the MIT license or Apache 2.0:
536
+
537
+ ```json
538
+ {
539
+ "license": "Apache-2.0 OR MIT"
540
+ }
541
+ ```
542
+
543
+ Some major projects include exceptions;
544
+ the Microsoft C++ standard library, and the LLVM project,
545
+ are licensed under Apache 2.0 with the LLVM exception:
546
+
547
+ ```json
548
+ {
549
+ "license": "Apache-2.0 WITH LLVM-exception"
550
+ }
551
+ ```
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/portfile-functions.md ADDED
@@ -0,0 +1,83 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ <!-- Run regenerate.ps1 to extract scripts documentation -->
2
+
3
+ # Portfile helper functions
4
+ - [execute\_process](execute_process.md)
5
+ - [vcpkg\_acquire\_msys](vcpkg_acquire_msys.md)
6
+ - [vcpkg\_add\_to\_path](vcpkg_add_to_path.md)
7
+ - [vcpkg\_apply\_patches](vcpkg_apply_patches.md) (deprecated)
8
+ - [vcpkg\_backup\_restore\_env\_vars](vcpkg_backup_restore_env_vars.md)
9
+ - [vcpkg\_build\_cmake](vcpkg_build_cmake.md) (deprecated, use [vcpkg\_cmake\_build](ports/vcpkg-cmake/vcpkg_cmake_build.md))
10
+ - [vcpkg\_build\_make](vcpkg_build_make.md)
11
+ - [vcpkg\_build\_msbuild](vcpkg_build_msbuild.md)
12
+ - [vcpkg\_build\_ninja](vcpkg_build_ninja.md)
13
+ - [vcpkg\_build\_nmake](vcpkg_build_nmake.md)
14
+ - [vcpkg\_build\_qmake](vcpkg_build_qmake.md)
15
+ - [vcpkg\_buildpath\_length\_warning](vcpkg_buildpath_length_warning.md)
16
+ - [vcpkg\_check\_features](vcpkg_check_features.md)
17
+ - [vcpkg\_check\_linkage](vcpkg_check_linkage.md)
18
+ - [vcpkg\_clean\_executables\_in\_bin](vcpkg_clean_executables_in_bin.md)
19
+ - [vcpkg\_clean\_msbuild](vcpkg_clean_msbuild.md)
20
+ - [vcpkg\_common\_definitions](vcpkg_common_definitions.md)
21
+ - [vcpkg\_configure\_cmake](vcpkg_configure_cmake.md) (deprecated, use [vcpkg\_cmake\_configure](ports/vcpkg-cmake/vcpkg_cmake_configure.md))
22
+ - [vcpkg\_configure\_gn](vcpkg_configure_gn.md) (deprecated, use [vcpkg\_gn\_configure](ports/vcpkg-gn/vcpkg_gn_configure.md))
23
+ - [vcpkg\_configure\_make](vcpkg_configure_make.md)
24
+ - [vcpkg\_configure\_meson](vcpkg_configure_meson.md)
25
+ - [vcpkg\_configure\_qmake](vcpkg_configure_qmake.md)
26
+ - [vcpkg\_copy\_pdbs](vcpkg_copy_pdbs.md)
27
+ - [vcpkg\_copy\_tool\_dependencies](vcpkg_copy_tool_dependencies.md)
28
+ - [vcpkg\_copy\_tools](vcpkg_copy_tools.md)
29
+ - [vcpkg\_download\_distfile](vcpkg_download_distfile.md)
30
+ - [vcpkg\_execute\_build\_process](vcpkg_execute_build_process.md)
31
+ - [vcpkg\_execute\_in\_download\_mode](vcpkg_execute_in_download_mode.md)
32
+ - [vcpkg\_execute\_required\_process](vcpkg_execute_required_process.md)
33
+ - [vcpkg\_execute\_required\_process\_repeat](vcpkg_execute_required_process_repeat.md)
34
+ - [vcpkg\_extract\_source\_archive](vcpkg_extract_source_archive.md)
35
+ - [vcpkg\_extract\_source\_archive\_ex](vcpkg_extract_source_archive_ex.md)
36
+ - [vcpkg\_fail\_port\_install](vcpkg_fail_port_install.md) (deprecated)
37
+ - [vcpkg\_find\_acquire\_program](vcpkg_find_acquire_program.md)
38
+ - [vcpkg\_find\_fortran](vcpkg_find_fortran.md)
39
+ - [vcpkg\_fixup\_cmake\_targets](vcpkg_fixup_cmake_targets.md) (deprecated, use [vcpkg\_cmake\_config\_fixup](ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md))
40
+ - [vcpkg\_fixup\_pkgconfig](vcpkg_fixup_pkgconfig.md)
41
+ - [vcpkg\_from\_bitbucket](vcpkg_from_bitbucket.md)
42
+ - [vcpkg\_from\_git](vcpkg_from_git.md)
43
+ - [vcpkg\_from\_github](vcpkg_from_github.md)
44
+ - [vcpkg\_from\_gitlab](vcpkg_from_gitlab.md)
45
+ - [vcpkg\_from\_sourceforge](vcpkg_from_sourceforge.md)
46
+ - [vcpkg\_get\_program\_files\_platform\_bitness](vcpkg_get_program_files_platform_bitness.md)
47
+ - [vcpkg\_get\_windows\_sdk](vcpkg_get_windows_sdk.md)
48
+ - [vcpkg\_host\_path\_list](vcpkg_host_path_list.md)
49
+ - [vcpkg\_install\_cmake](vcpkg_install_cmake.md) (deprecated, use [vcpkg\_cmake\_install](ports/vcpkg-cmake/vcpkg_cmake_install.md))
50
+ - [vcpkg\_install\_gn](vcpkg_install_gn.md) (deprecated, use [vcpkg\_gn\_install](ports/vcpkg-gn/vcpkg_gn_install.md))
51
+ - [vcpkg\_install\_make](vcpkg_install_make.md)
52
+ - [vcpkg\_install\_meson](vcpkg_install_meson.md)
53
+ - [vcpkg\_install\_msbuild](vcpkg_install_msbuild.md)
54
+ - [vcpkg\_install\_nmake](vcpkg_install_nmake.md)
55
+ - [vcpkg\_install\_qmake](vcpkg_install_qmake.md)
56
+ - [vcpkg\_list](vcpkg_list.md)
57
+ - [vcpkg\_minimum\_required](vcpkg_minimum_required.md)
58
+ - [vcpkg\_replace\_string](vcpkg_replace_string.md)
59
+
60
+ ## Internal Functions
61
+
62
+ - [z\_vcpkg\_apply\_patches](internal/z_vcpkg_apply_patches.md)
63
+ - [z\_vcpkg\_forward\_output\_variable](internal/z_vcpkg_forward_output_variable.md)
64
+ - [z\_vcpkg\_function\_arguments](internal/z_vcpkg_function_arguments.md)
65
+ - [z\_vcpkg\_get\_cmake\_vars](internal/z_vcpkg_get_cmake_vars.md)
66
+ - [z\_vcpkg\_prettify\_command\_line](internal/z_vcpkg_prettify_command_line.md)
67
+
68
+ ## Scripts from Ports
69
+
70
+ ### [vcpkg-cmake](ports/vcpkg-cmake.md)
71
+
72
+ - [vcpkg\_cmake\_build](ports/vcpkg-cmake/vcpkg_cmake_build.md)
73
+ - [vcpkg\_cmake\_configure](ports/vcpkg-cmake/vcpkg_cmake_configure.md)
74
+ - [vcpkg\_cmake\_get\_vars](ports/vcpkg-cmake/vcpkg_cmake_get_vars.md)
75
+ - [vcpkg\_cmake\_install](ports/vcpkg-cmake/vcpkg_cmake_install.md)
76
+
77
+ ### [vcpkg-cmake-config](ports/vcpkg-cmake-config.md)
78
+
79
+ - [vcpkg\_cmake\_config\_fixup](ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md)
80
+
81
+ ### [vcpkg-pkgconfig-get-modules](ports/vcpkg-pkgconfig-get-modules.md)
82
+
83
+ - [x\_vcpkg\_pkgconfig\_get\_modules](ports/vcpkg-pkgconfig-get-modules/x_vcpkg_pkgconfig_get_modules.md)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake-config.md ADDED
@@ -0,0 +1,10 @@
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg-cmake-config
2
+
3
+ `vcpkg-cmake-config` provides `vcpkg_cmake_config_fixup()`,
4
+ a function which both:
5
+
6
+ - Fixes common mistakes in port build systems, like using absolute paths
7
+ - Merges the debug and release config files.
8
+
9
+ This function should almost always be used when a port has `*config.cmake` files,
10
+ even when the buildsystem of the project is not CMake.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md ADDED
@@ -0,0 +1,54 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_cmake_config_fixup
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.md).
4
+
5
+ Merge release and debug CMake targets and configs to support multiconfig generators.
6
+
7
+ Additionally corrects common issues with targets, such as absolute paths and incorrectly placed binaries.
8
+
9
+ ```cmake
10
+ vcpkg_cmake_config_fixup(
11
+ [PACKAGE_NAME <name>]
12
+ [CONFIG_PATH <config-directory>]
13
+ [TOOLS_PATH <tools/${PORT}>]
14
+ [DO_NOT_DELETE_PARENT_CONFIG_PATH]
15
+ [NO_PREFIX_CORRECTION]
16
+ )
17
+ ```
18
+
19
+ For many ports, `vcpkg_cmake_config_fixup()` on its own should work,
20
+ as `PACKAGE_NAME` defaults to `${PORT}` and `CONFIG_PATH` defaults to `share/${PACKAGE_NAME}`.
21
+ For ports where the package name passed to `find_package` is distinct from the port name,
22
+ `PACKAGE_NAME` should be changed to be that name instead.
23
+ For ports where the directory of the `*config.cmake` files cannot be set,
24
+ use the `CONFIG_PATH` to change the directory where the files come from.
25
+
26
+ By default the parent directory of CONFIG_PATH is removed if it is named "cmake".
27
+ Passing the `DO_NOT_DELETE_PARENT_CONFIG_PATH` option disable such behavior,
28
+ as it is convenient for ports that install
29
+ more than one CMake package configuration file.
30
+
31
+ The `NO_PREFIX_CORRECTION` option disables the correction of `_IMPORT_PREFIX`
32
+ done by vcpkg due to moving the config files.
33
+ Currently the correction does not take into account how the files are moved,
34
+ and applies a rather simply correction which in some cases will yield the wrong results.
35
+
36
+ ## How it Works
37
+
38
+ 1. Moves `/debug/<CONFIG_PATH>/*targets-debug.cmake` to `/share/${PACKAGE_NAME}`.
39
+ 2. Transforms all references matching `/bin/*.exe` to `/${TOOLS_PATH}/*.exe` on Windows.
40
+ 3. Transforms all references matching `/bin/*` to `/${TOOLS_PATH}/*` on other platforms.
41
+ 4. Fixes `${_IMPORT_PREFIX}` in auto generated targets.
42
+ 5. Replaces `${CURRENT_INSTALLED_DIR}` with `${_IMPORT_PREFIX}` in configs.
43
+ 6. Merges INTERFACE_LINK_LIBRARIES of release and debug configurations.
44
+ 7. Replaces `${CURRENT_INSTALLED_DIR}` with `${VCPKG_IMPORT_PREFIX}` in targets.
45
+ 8. Removes `/debug/<CONFIG_PATH>/*config.cmake`.
46
+
47
+ ## Examples
48
+
49
+ * [concurrentqueue](https://github.com/Microsoft/vcpkg/blob/master/ports/concurrentqueue/portfile.cmake)
50
+ * [curl](https://github.com/Microsoft/vcpkg/blob/master/ports/curl/portfile.cmake)
51
+ * [nlohmann-json](https://github.com/Microsoft/vcpkg/blob/master/ports/nlohmann-json/portfile.cmake)
52
+
53
+ ## Source
54
+ [ports/vcpkg-cmake-config/vcpkg\_cmake\_config\_fixup.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake.md ADDED
@@ -0,0 +1,7 @@
 
 
 
 
 
 
 
 
1
+ # vcpkg-cmake
2
+
3
+ This port contains cmake functions for dealing with a CMake buildsystem.
4
+
5
+ In the common case, `vcpkg_cmake_configure()` (with appropriate arguments)
6
+ followed by `vcpkg_cmake_install()` will be enough to build and install a port.
7
+ `vcpkg_cmake_build()` is provided for more complex cases.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_build.md ADDED
@@ -0,0 +1,38 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_cmake_build
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_build.md).
4
+
5
+ Build a cmake project.
6
+
7
+ ```cmake
8
+ vcpkg_cmake_build(
9
+ [TARGET <target>]
10
+ [LOGFILE_BASE <base>]
11
+ [DISABLE_PARALLEL]
12
+ [ADD_BIN_TO_PATH]
13
+ )
14
+ ```
15
+
16
+ `vcpkg_cmake_build` builds an already-configured cmake project.
17
+ You can use the alias [`vcpkg_cmake_install()`] function
18
+ if your CMake build system supports the `install` TARGET,
19
+ and this is something we recommend doing whenever possible.
20
+ Otherwise, you can use `TARGET` to set the target to build.
21
+ This function defaults to not passing a target to cmake.
22
+
23
+ [`vcpkg_cmake_install()`]: vcpkg_cmake_install.md
24
+
25
+ `LOGFILE_BASE` is used to set the base of the logfile names;
26
+ by default, this is `build`, and thus the logfiles end up being something like
27
+ `build-x86-windows-dbg.log`; if you use `vcpkg_cmake_install`,
28
+ this is set to `install`, so you'll get log names like `install-x86-windows-dbg.log`.
29
+
30
+ For build systems that are buggy when run in parallel,
31
+ using `DISABLE_PARALLEL` will run the build with only one job.
32
+
33
+ Finally, `ADD_BIN_TO_PATH` adds the appropriate (either release or debug)
34
+ `bin/` directories to the path during the build,
35
+ such that executables run during the build will be able to access those DLLs.
36
+
37
+ ## Source
38
+ [ports/vcpkg-cmake/vcpkg\_cmake\_build.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-cmake/vcpkg_cmake_build.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_configure.md ADDED
@@ -0,0 +1,93 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_cmake_configure
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_configure.md).
4
+
5
+ Configure a CMake buildsystem.
6
+
7
+ ```cmake
8
+ vcpkg_cmake_configure(
9
+ SOURCE_PATH <source-path>
10
+ [LOGFILE_BASE <logname-base>]
11
+ [DISABLE_PARALLEL_CONFIGURE]
12
+ [NO_CHARSET_FLAG]
13
+ [WINDOWS_USE_MSBUILD]
14
+ [GENERATOR <generator>]
15
+ [OPTIONS
16
+ <configure-setting>...]
17
+ [OPTIONS_RELEASE
18
+ <configure-setting>...]
19
+ [OPTIONS_DEBUG
20
+ <configure-setting>...]
21
+ [MAYBE_UNUSED_VARIABLES
22
+ <option-name>...]
23
+ )
24
+ ```
25
+
26
+ `vcpkg_cmake_configure` configures a CMake build system for use with
27
+ `vcpkg_cmake_buildsystem_build` and `vcpkg_cmake_buildsystem_install`.
28
+ `source-path` is where the source is located; by convention,
29
+ this is usually `${SOURCE_PATH}`, which is set by one of the `vcpkg_from_*` functions.
30
+ This function configures the build system for both Debug and Release builds by default,
31
+ assuming that `VCPKG_BUILD_TYPE` is not set; if it is, then it will only configure for
32
+ that build type.
33
+
34
+ Use the `OPTIONS` argument to set the configure settings for both release and debug,
35
+ and use `OPTIONS_RELEASE` and `OPTIONS_DEBUG` to set the configure settings for
36
+ release only and debug only respectively.
37
+
38
+ By default, when possible, `vcpkg_cmake_configure` uses [ninja-build]
39
+ as its build system. If the `WINDOWS_USE_MSBUILD` argument is passed, then
40
+ `vcpkg_cmake_configure` will use a Visual Studio generator on Windows;
41
+ on every other platform, `vcpkg_cmake_configure` just uses Ninja.
42
+
43
+ [ninja-build]: https://ninja-build.org/
44
+
45
+ Additionally, one may pass the specific generator a port should use with `GENERATOR`.
46
+ This is useful if some project-specific buildsystem
47
+ has been wrapped in a CMake build system that doesn't perform an actual build.
48
+ If used for this purpose, it should be set to `"NMake Makefiles"`.
49
+ `vcpkg_cmake_buildsystem_build` and `install` do not support this being set to anything
50
+ except for NMake.
51
+
52
+ For libraries which cannot be configured in parallel,
53
+ pass the `DISABLE_PARALLEL_CONFIGURE` flag. This is needed, for example,
54
+ if the library's build system writes back into the source directory during configure.
55
+ This also disables the `CMAKE_DISABLE_SOURCE_CHANGES` option.
56
+
57
+ By default, this function adds flags to `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS`
58
+ which set the default character set to utf-8 for MSVC.
59
+ If the library sets its own code page, pass the `NO_CHARSET_FLAG` option.
60
+
61
+ This function makes certain that all options passed in are used by the
62
+ underlying CMake build system. If there are options that might be unused,
63
+ perhaps on certain platforms, pass those variable names to
64
+ `MAYBE_UNUSED_VARIABLES`. For example:
65
+ ```cmake
66
+ vcpkg_cmake_configure(
67
+ ...
68
+ OPTIONS
69
+ -DBUILD_EXAMPLE=OFF
70
+ ...
71
+ MAYBE_UNUSED_VARIABLES
72
+ BUILD_EXAMPLE
73
+ )
74
+ ```
75
+
76
+ `LOGFILE_BASE` is used to set the base of the logfile names;
77
+ by default, this is `config`, and thus the logfiles end up being something like
78
+ `config-x86-windows-dbg.log`. You can set it to anything you like;
79
+ if you set it to `config-the-first`,
80
+ you'll get something like `config-the-first-x86-windows.dbg.log`.
81
+
82
+ ## Notes
83
+ This command supplies many common arguments to CMake. To see the full list, examine the source.
84
+
85
+ ## Examples
86
+
87
+ * [zlib](https://github.com/Microsoft/vcpkg/blob/master/ports/zlib/portfile.cmake)
88
+ * [cpprestsdk](https://github.com/Microsoft/vcpkg/blob/master/ports/cpprestsdk/portfile.cmake)
89
+ * [poco](https://github.com/Microsoft/vcpkg/blob/master/ports/poco/portfile.cmake)
90
+ * [opencv4](https://github.com/Microsoft/vcpkg/blob/master/ports/opencv4/portfile.cmake)
91
+
92
+ ## Source
93
+ [ports/vcpkg-cmake/vcpkg\_cmake\_configure.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-cmake/vcpkg_cmake_configure.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_get_vars.md ADDED
@@ -0,0 +1,41 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_cmake_get_vars
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_get_vars.md).
4
+
5
+ Runs a cmake configure with a dummy project to extract certain cmake variables
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_cmake_get_vars(<out-var>)
10
+ ```
11
+
12
+ `vcpkg_cmake_get_vars(<out-var>)` sets `<out-var>` to
13
+ a path to a generated CMake file, with the detected `CMAKE_*` variables
14
+ re-exported as `VCPKG_DETECTED_CMAKE_*`.
15
+
16
+ Additionally sets, for `RELEASE` and `DEBUG`:
17
+ - VCPKG_COMBINED_CXX_FLAGS_<config>
18
+ - VCPKG_COMBINED_C_FLAGS_<config>
19
+ - VCPKG_COMBINED_SHARED_LINKER_FLAGS_<config>
20
+ - VCPKG_COMBINED_STATIC_LINKER_FLAGS_<config>
21
+ - VCPKG_COMBINED_EXE_LINKER_FLAGS_<config>
22
+
23
+ Most users should use these pre-combined flags instead of attempting
24
+ to read the `VCPKG_DETECTED_*` flags directly.
25
+
26
+ ## Notes
27
+ Avoid usage in portfiles.
28
+
29
+ All calls to `vcpkg_cmake_get_vars` will result in the same output file;
30
+ the output file is not generated multiple times.
31
+
32
+ ### Basic Usage
33
+
34
+ ```cmake
35
+ vcpkg_cmake_get_vars(cmake_vars_file)
36
+ include("${cmake_vars_file}")
37
+ message(STATUS "detected CXX flags: ${VCPKG_DETECTED_CMAKE_CXX_FLAGS}")
38
+ ```
39
+
40
+ ## Source
41
+ [ports/vcpkg-cmake/vcpkg\_cmake\_get\_vars.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-cmake/vcpkg_cmake_get_vars.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_install.md ADDED
@@ -0,0 +1,25 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_cmake_install
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-cmake/vcpkg_cmake_install.md).
4
+
5
+ Build and install a cmake project.
6
+
7
+ ```cmake
8
+ vcpkg_cmake_install(
9
+ [DISABLE_PARALLEL]
10
+ [ADD_BIN_TO_PATH]
11
+ )
12
+ ```
13
+
14
+ `vcpkg_cmake_install` transparently forwards to [`vcpkg_cmake_build()`],
15
+ with additional parameters to set the `TARGET` to `install`,
16
+ and to set the `LOGFILE_ROOT` to `install` as well.
17
+
18
+ [`vcpkg_cmake_build()`]: vcpkg_cmake_build.md
19
+
20
+ ## Examples:
21
+
22
+ * [zlib](https://github.com/Microsoft/vcpkg/blob/master/ports/zlib/portfile.cmake)
23
+
24
+ ## Source
25
+ [ports/vcpkg-cmake/vcpkg\_cmake\_install.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-cmake/vcpkg_cmake_install.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-pkgconfig-get-modules.md ADDED
@@ -0,0 +1,6 @@
 
 
 
 
 
 
 
1
+ # vcpkg-pkgconfig-get-modules
2
+
3
+ **Experimental: will change or be removed at any time**
4
+
5
+ `vcpkg-pkgconfig-get-modules` provides `x_vcpkg_pkgconfig_get_modules()`, a function which simplifies calling
6
+ `pkg-config` in portfiles in order to gather dependencies for exotic buildsystems.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/ports/vcpkg-pkgconfig-get-modules/x_vcpkg_pkgconfig_get_modules.md ADDED
@@ -0,0 +1,45 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # x_vcpkg_pkgconfig_get_modules
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/ports/vcpkg-pkgconfig-get-modules/x_vcpkg_pkgconfig_get_modules.md).
4
+
5
+ Experimental
6
+ Retrieve required module information from pkgconfig modules
7
+
8
+ ## Usage
9
+ ```cmake
10
+ x_vcpkg_pkgconfig_get_modules(
11
+ PREFIX <prefix>
12
+ MODULES <pkgconfig_modules>...
13
+ [CFLAGS]
14
+ [LIBS]
15
+ [LIBRARIES]
16
+ [LIBRARIES_DIRS]
17
+ [INCLUDE_DIRS]
18
+ )
19
+ ```
20
+ ## Parameters
21
+
22
+ ### PREFIX
23
+ Used variable prefix to use
24
+
25
+ ### MODULES
26
+ List of pkgconfig modules to retrieve information for.
27
+
28
+ ### LIBS
29
+ Returns `"${PKGCONFIG}" --libs` in <prefix>_LIBS_(DEBUG|RELEASE)
30
+
31
+ ### LIBRARIES
32
+ Returns `"${PKGCONFIG}" --libs-only-l` in <prefix>_LIBRARIES_(DEBUG|RELEASE)
33
+
34
+ ### LIBRARIES_DIRS
35
+ Returns `"${PKGCONFIG}" --libs-only-L` in <prefix>_LIBRARIES_DIRS_(DEBUG|RELEASE)
36
+
37
+ ### INCLUDE_DIRS
38
+ Returns `"${PKGCONFIG}" --cflags-only-I` in <prefix>_INCLUDE_DIRS_(DEBUG|RELEASE)
39
+
40
+ ## Examples
41
+
42
+ * [qt5-base](https://github.com/microsoft/vcpkg/blob/master/ports/qt5-base/portfile.cmake)
43
+
44
+ ## Source
45
+ [ports/vcpkg-pkgconfig-get-modules/x\_vcpkg\_pkgconfig\_get\_modules.cmake](https://github.com/Microsoft/vcpkg/blob/master/ports/vcpkg-pkgconfig-get-modules/x_vcpkg_pkgconfig_get_modules.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/pr-review-checklist.md ADDED
@@ -0,0 +1,115 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ Vcpkg PR Checklist
2
+ =====================
3
+ Revision: 1
4
+
5
+ ## Overview
6
+ This document provides an annotated checklist which vcpkg team members use to apply the "reviewed" label on incoming pull requests. If a pull request violates any of these points, we may ask contributors to make necessary changes before we can merge the changeset.
7
+
8
+ Feel free to create an issue or pull request if you feel that this checklist can be improved. Please increment the revision number when modifying the checklist content.
9
+
10
+ ## Checklist
11
+ You can link any of these checklist items in a GitHub comment by copying the link address attached to each item code.
12
+
13
+ <details id="c000001">
14
+ <summary><a href="#c000001">c000001</a>: No deprecated helper functions are used</summary>
15
+
16
+ See our [Maintainer Guidelines and Policies](maintainer-guide.md#Avoid-deprecated-helper-functions) for more information.
17
+
18
+ </details>
19
+
20
+ <details id="c000002">
21
+ <summary><a href="#c000002">c000002</a>: `"port-version"` field is updated</summary>
22
+
23
+ See our [Maintainer Guidelines and Policies](maintainer-guide.md#versioning) for more information.
24
+
25
+ </details>
26
+
27
+ <details id="c000003">
28
+ <summary><a href="#c000003">c000003</a>: New ports contain a `"description"` field written in English</summary>
29
+
30
+ A description only one or a few sentences long is helpful. Consider using the library's official description from their `README.md` or similar if possible. Automatic translations are acceptable and we are happy to clean up translations to English for our contributors.
31
+
32
+ See our [manifest file documentation](manifest-files.md#description) for more information.
33
+
34
+ </details>
35
+
36
+ <details id="c000004">
37
+ <summary><a href="#c000004">c000004</a>: No unnecessary comments are present in the changeset</summary>
38
+
39
+ See our [Maintainer Guidelines and Policies](maintainer-guide.md#Avoid-excessive-comments-in-portfiles) for more information.
40
+
41
+ </details>
42
+
43
+ <details id="c000005">
44
+ <summary><a href="#c000005">c000005</a>: Downloaded archives are versioned if available</summary
45
+
46
+ To ensure archive content does not change, archives downloaded preferably have an associated version tag that can be incremented alongside the port's `"version"`.
47
+
48
+ </details>
49
+
50
+ <details id="c000006">
51
+ <summary><a href="#c000006">c000006</a>: New ports pass CI checks for triplets that the library officially supports</summary>
52
+
53
+ To ensure vcpkg ports are of a high quality, we ask that incoming ports support the official platforms for the library in question.
54
+
55
+ </details>
56
+
57
+ <details id="c000007">
58
+ <summary><a href="#c000007">c000007</a>: Patches fix issues that are vcpkg-specific only</summary>
59
+
60
+ If possible, patches to the library source code should be upstreamed to the library's official repository. Opening up a pull request on the library's repository will help to improve the library for everyone, not just vcpkg users.
61
+
62
+ </details>
63
+
64
+ <details id="c000008">
65
+ <summary><a href="#c000008">c000008</a>: New ports download source code from the official source if available</summary>
66
+
67
+ To respect library authors and keep code secure, please have ports download source code from the official source. We may make exceptions if the original source code is not available and there is substantial community interest in maintaining the library in question.
68
+
69
+ </details>
70
+
71
+ <details id="c000009">
72
+ <summary><a href="#c000009">c000009</a>: Ports and port features are named correctly</summary>
73
+
74
+ For user accessibility, we prefer names of ports and port features to be intuitive and close to their counterparts in official sources and other package managers. If you are unsure about the naming of a port or port feature, we recommend checking repology.org, packages.ubuntu.com, or searching for additional information using a search engine. We can also help our contributors with this, so feel free to ask for naming suggestions if you are unsure.
75
+
76
+ </details>
77
+
78
+ <details id="c000010">
79
+ <summary><a href="#c000010">c000010</a>: Library targets are exported when appropriate</summary>
80
+
81
+ To provide users with a seamless build system integration, please be sure to export and provide a means of finding the library targets intended to be used downstream. Targets not meant to be exported should be be marked private and not exported.
82
+
83
+ </details>
84
+
85
+ <details id="c000011">
86
+ <summary><a href="#c000011">c000011</a>: Ports do not use applications which modify the user's system</summary>
87
+
88
+ Ports should uphold vcpkg's contract of not modifying the user's system by avoiding applications which do so. Examples of these applications are `sudo`, `apt`, `brew`, or `pip`. Please use an alternative to these types of programs wherever possible.
89
+
90
+ </details>
91
+
92
+ <details id="c000012">
93
+ <summary><a href="#c000012">c000012</a>: Ports with system dependencies include an information message during installation</summary>
94
+
95
+ Some ports have library and tool dependencies that do not exist within vcpkg. For these missing dependencies, we ask that contributors add a message to the top of the port's `portfile.cmake` stating the missing dependencies and how to acquire them. We ask that the message is displayed before any major work is done to ensure that users can "early out" of the installation process as soon as possible in case they are missing the dependency.
96
+
97
+ Example:
98
+ ```cmake
99
+ message(
100
+ "${PORT} currently requires the following libraries from the system package manager:
101
+ autoconf libtool
102
+ These can be installed on Ubuntu systems via sudo apt install autoconf libtool"
103
+ )
104
+ ```
105
+
106
+ </details>
107
+
108
+ <details id="c000013">
109
+ <summary><a href="#c000013">c000013</a>: Manifest files are used instead of CONTROL files for new ports</summary>
110
+
111
+ Many existing ports use the CONTROL file syntax; while this syntax will be supported for some time to come,
112
+ new ports should not use these. Any newly added port _must_ use the manifest files.
113
+
114
+ We also recommend, when significant modifications are made to ports, that one switches to manifest files;
115
+ however, this is not required. You may find `vcpkg format-manifest` useful.
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/registries.md ADDED
@@ -0,0 +1,365 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Creating Registries
2
+
3
+ **The latest version of this documentation is available on [GitHub](https://github.com/Microsoft/vcpkg/tree/master/docs/maintainers/registries.md).**
4
+
5
+ There are two parts to using registries; this documents the creation side of
6
+ the relationship. In order to learn more about using registries that others
7
+ have created, please read [this documentation](../users/registries.md).
8
+ ## Table of Contents
9
+
10
+ - [Creating Registries](#creating-registries)
11
+ - [Table of Contents](#table-of-contents)
12
+ - [Overview](#overview)
13
+ - [Git Registries](#git-registries)
14
+ - [Adding a New Version](#adding-a-new-version)
15
+ - [Filesystem Registries](#filesystem-registries)
16
+ - [Adding a New Version](#adding-a-new-version-1)
17
+ - [Builtin Registries](#builtin-registries)
18
+
19
+ ## Overview
20
+
21
+ Registries are collections of ports and their versions. There are two major
22
+ choices of implementation for registries, if you want to create your own -
23
+ git registries, and filesystem registries.
24
+
25
+ Git registries are simple git repositories, and can be shared publicly or
26
+ privately via normal mechanisms for git repositories. The vcpkg repository at
27
+ <https://github.com/microsoft/vcpkg>, for example, is a git registry.
28
+
29
+ Filesystem registries are designed as more of a testing ground. Given that they
30
+ literally live on your filesystem, the only way to share them is via shared
31
+ directories. However, filesystem registries can be useful as a way to represent
32
+ registries held in non-git version control systems, assuming one has some way
33
+ to get the registry onto the disk.
34
+
35
+ Note that we expect the set of registry types to grow over time; if you would
36
+ like support for registries built in your favorite public version control
37
+ system, don't hesitate to open a PR.
38
+
39
+ The basic structure of a registry is:
40
+
41
+ - The set of versions that are considered "latest" at certain times in history,
42
+ known as the "baseline".
43
+ - The set of all the versions of all the ports, and where to find each of
44
+ these in the registry.
45
+
46
+ ### Git Registries
47
+
48
+ As you're following along with this documentation, it may be helpful to have
49
+ a working example to refer to. We've written one and put it here:
50
+ <https://github.com/northwindtraders/vcpkg-registry>.
51
+
52
+ All git registries must have a `versions/baseline.json` file. This file
53
+ contains the set of "latest versions" at a certain commit. It is laid out as
54
+ a top-level object containing only the `"default"` field. This field should
55
+ contain an object mapping port names to the version which is currently the
56
+ latest.
57
+
58
+ Here's an example of a valid baseline.json:
59
+
60
+ ```json
61
+ {
62
+ "default": {
63
+ "kitten": {
64
+ "baseline": "2.6.2",
65
+ "port-version": 0
66
+ },
67
+ "port-b": {
68
+ "baseline": "19.00",
69
+ "port-version": 2
70
+ }
71
+ }
72
+ }
73
+ ```
74
+
75
+ The `versions` directory contains all the information about which versions of
76
+ which packages are contained in the registry, along with where those versions
77
+ are stored. The rest of the registry just acts as a backing store, as far as
78
+ vcpkg is concerned: only things inside the `versions` directory will be used
79
+ to direct how your registry is seen by vcpkg.
80
+
81
+ Each port in a registry should exist in the versions directory as
82
+ `<first letter of port>-/<name of port>.json`; in other words, the
83
+ information about the `kitten` port would be located in
84
+ `versions/k-/kitten.json`. This should be a top-level object with only a
85
+ single field: `"versions"`. This field should contain an array of version
86
+ objects:
87
+
88
+ - The version of the port in question; should be exactly the same as the
89
+ `vcpkg.json` file, including the version fields and `"port-version"`.
90
+ - The `"git-tree"` field, which is a git tree; in other words, what you get
91
+ when you write `git rev-parse COMMIT-ID:path/to/port`.
92
+
93
+ Note that the version fields for ports with `CONTROL` files, is
94
+ `"version-string"`; we do not recommend using `CONTROL` files in new
95
+ registries, however.
96
+
97
+ _WARNING_: One very important part of registries is that versions should
98
+ _never_ be changed. Updating to a later ref should never remove or change an
99
+ existing version. It must always be safe to update a registry.
100
+
101
+ Here's an example of a valid version database for a `kitten` port with one
102
+ version:
103
+
104
+ ```json
105
+ {
106
+ "versions": [
107
+ {
108
+ "version": "2.6.2",
109
+ "port-version": 0,
110
+ "git-tree": "67d60699c271b7716279fdea5a5c6543929eb90e"
111
+ }
112
+ ]
113
+ }
114
+ ```
115
+
116
+ In general, it's not important where you place port directories. However, the
117
+ idiom in vcpkg is to follow what the built in vcpkg registry does: your
118
+ `kitten` port should be placed in `ports/kitten`.
119
+
120
+ _WARNING_: One other thing to keep in mind is that when you update a registry,
121
+ all previous versions should also be accessible. Since your user will set their
122
+ baseline to a commit ID, that commit ID must always exist, and be accessible
123
+ from your HEAD commit, which is what is actually fetched. This means that your
124
+ HEAD commit should be a child of all previous HEAD commits.
125
+
126
+ ### Builtin Registries
127
+
128
+ Builtin registries are treated as special Git registries. Instead of fetching
129
+ from a remote url, builtin registries consult the `$VCPKG_ROOT/.git` directory
130
+ of the vcpkg clone. They use the currently checked out `$VCPKG_ROOT/versions`
131
+ directory as the source for versioning information.
132
+
133
+ #### Adding a New Version
134
+
135
+ There is some git trickery involved in creating a new version of a port. The
136
+ first thing to do is make some changes, update the `"port-version"` and regular
137
+ version field as you need to, and then test with `overlay-ports`:
138
+ `vcpkg install kitten --overlay-ports=ports/kitten`.
139
+
140
+ Once you've finished your testing, you'll need to make sure that the directory
141
+ as it is is under git's purview. You'll do this by creating a temporary commit:
142
+
143
+ ```pwsh
144
+ > git add ports/kitten
145
+ > git commit -m 'temporary commit'
146
+ ```
147
+
148
+ Then, get the git tree ID of the directory:
149
+
150
+ ```pwsh
151
+ > git rev-parse HEAD:ports/kitten
152
+ 73ad3c823ef701c37421b450a34271d6beaf7b07
153
+ ```
154
+
155
+ Then, you can add this version to the versions database. At the top of your
156
+ `versions/k-/kitten.json`, you can add (assuming you're adding version
157
+ `2.6.3#0`):
158
+
159
+ ```json
160
+ {
161
+ "versions": [
162
+ {
163
+ "version": "2.6.3",
164
+ "port-version": 0,
165
+ "git-tree": "73ad3c823ef701c37421b450a34271d6beaf7b07"
166
+ },
167
+ {
168
+ "version": "2.6.2",
169
+ "port-version": 0,
170
+ "git-tree": "67d60699c271b7716279fdea5a5c6543929eb90e"
171
+ }
172
+ ]
173
+ }
174
+ ```
175
+
176
+ then, you'll want to modify your `versions/baseline.json` with your new version
177
+ as well:
178
+
179
+ ```json
180
+ {
181
+ "default": {
182
+ "kitten": {
183
+ "baseline": "2.6.3",
184
+ "port-version": 0
185
+ },
186
+ "port-b": {
187
+ "baseline": "19.00",
188
+ "port-version": 2
189
+ }
190
+ }
191
+ }
192
+ ```
193
+
194
+ and amend your current commit:
195
+
196
+ ```pwsh
197
+ > git commit --amend
198
+ ```
199
+
200
+ then share away!
201
+
202
+ ### Filesystem Registries
203
+
204
+ As you're following along with this documentation, it may be helpful to have
205
+ a working example to refer to. We've written one and put it here:
206
+ <https://github.com/vcpkg/example-filesystem-registry>.
207
+
208
+ All filesystem registries must have a `versions/baseline.json` file. This file
209
+ contains the set of "latest versions" for a certain version of the registry.
210
+ It is laid out as a top-level object containing a map from version name to
211
+ "baseline objects", which map port names to the version which is considered
212
+ "latest" for that version of the registry.
213
+
214
+ Filesystem registries need to decide on a versioning scheme. Unlike git
215
+ registries, which have the implicit versioning scheme of refs, filesystem
216
+ registries can't rely on the version control system here. One possible option
217
+ is to do a daily release, and have your "versions" be dates.
218
+
219
+ _WARNING_: A baseline must always refer to the same set of versions. If you
220
+ want to add new versions, you need to create a new version of the registry in
221
+ the `baseline.json` file.
222
+
223
+ Here's an example of a valid `baseline.json`, for a registry that has decided
224
+ upon dates for their versions:
225
+
226
+ ```json
227
+ {
228
+ "2021-04-16": {
229
+ "kitten": {
230
+ "baseline": "2.6.2",
231
+ "port-version": 0
232
+ },
233
+ "port-b": {
234
+ "baseline": "19.00",
235
+ "port-version": 2
236
+ }
237
+ },
238
+ "2021-04-15": {
239
+ "kitten": {
240
+ "baseline": "2.6.2",
241
+ "port-version": 0
242
+ },
243
+ "port-b": {
244
+ "baseline": "19.00",
245
+ "port-version": 1
246
+ }
247
+ }
248
+ }
249
+ ```
250
+
251
+ The `versions` directory contains all the information about which versions of
252
+ which packages are contained in the registry, along with where those versions
253
+ are stored. The rest of the registry just acts as a backing store, as far as
254
+ vcpkg is concerned: only things inside the `versions` directory will be used
255
+ to direct how your registry is seen by vcpkg.
256
+
257
+ Each port in a registry should exist in the versions directory as
258
+ `<first letter of port>-/<name of port>.json`; in other words, the
259
+ information about the `kitten` port would be located in
260
+ `versions/k-/kitten.json`. This should be a top-level object with only a
261
+ single field: `"versions"`. This field should contain an array of version
262
+ objects:
263
+
264
+ - The version of the port in question; should be exactly the same as the
265
+ `vcpkg.json` file, including the version fields and `"port-version"`.
266
+ - The `"path"` field: a relative directory, rooted at the base of the registry
267
+ (in other words, the directory where `versions` is located), to the port
268
+ directory. It should look something like `"$/path/to/port/dir`"
269
+
270
+ Note that the version fields for ports with `CONTROL` files, is
271
+ `"version-string"`; we do not recommend using `CONTROL` files in new
272
+ registries, however.
273
+
274
+ In general, it's not important where you place port directories. However, the
275
+ idiom in vcpkg is to follow somewhat closely to what the built in vcpkg
276
+ registry does: your `kitten` port at version `x.y.z` should be placed in
277
+ `ports/kitten/x.y.z`, with port versions appended as you see fit (although
278
+ since `#` is not a good character to use for file names, perhaps use `_`).
279
+
280
+ _WARNING_: One very important part of registries is that versions should
281
+ _never_ be changed. One should never remove or change an existing version.
282
+ Your changes to your registry shouldn't change behavior to downstream users.
283
+
284
+ Here's an example of a valid version database for a `kitten` port with one
285
+ version:
286
+
287
+ ```json
288
+ {
289
+ "versions": [
290
+ {
291
+ "version": "2.6.2",
292
+ "port-version": 0,
293
+ "path": "$/ports/kitten/2.6.2_0"
294
+ }
295
+ ]
296
+ }
297
+ ```
298
+
299
+ #### Adding a New Version
300
+
301
+ Unlike git registries, adding a new version to a filesystem registry mostly
302
+ involves a lot of copying. The first thing to do is to copy the latest
303
+ version of your port into a new version directory, update the version and
304
+ `"port-version"` fields as you need to, and then test with `overlay-ports`:
305
+ `vcpkg install kitten --overlay-ports=ports/kitten/new-version`.
306
+
307
+ Once you've finished your testing, you can add this new version to the top of
308
+ your `versions/k-/kitten.json`:
309
+
310
+ ```json
311
+ {
312
+ "versions": [
313
+ {
314
+ "version": "2.6.3",
315
+ "port-version": 0,
316
+ "path": "$/ports/kitten/2.6.3_0"
317
+ },
318
+ {
319
+ "version": "2.6.2",
320
+ "port-version": 0,
321
+ "path": "$/ports/kitten/2.6.2_0"
322
+ }
323
+ ]
324
+ }
325
+ ```
326
+
327
+ then, you'll want to modify your `versions/baseline.json` with your new version
328
+ as well (remember not to modify existing baselines):
329
+
330
+ ```json
331
+ {
332
+ "2021-04-17": {
333
+ "kitten": {
334
+ "baseline": "2.6.3",
335
+ "port-version": 0
336
+ },
337
+ "port-b": {
338
+ "baseline": "19.00",
339
+ "port-version": 2
340
+ }
341
+ },
342
+ "2021-04-16": {
343
+ "kitten": {
344
+ "baseline": "2.6.2",
345
+ "port-version": 0
346
+ },
347
+ "port-b": {
348
+ "baseline": "19.00",
349
+ "port-version": 2
350
+ }
351
+ },
352
+ "2021-04-15": {
353
+ "kitten": {
354
+ "baseline": "2.6.2",
355
+ "port-version": 0
356
+ },
357
+ "port-b": {
358
+ "baseline": "19.00",
359
+ "port-version": 1
360
+ }
361
+ }
362
+ }
363
+ ```
364
+
365
+ and you're done!
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_acquire_msys.md ADDED
@@ -0,0 +1,60 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_acquire_msys
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_acquire_msys.md).
4
+
5
+ Download and prepare an MSYS2 instance.
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_acquire_msys(<MSYS_ROOT_VAR>
10
+ PACKAGES <package>...
11
+ [NO_DEFAULT_PACKAGES]
12
+ [DIRECT_PACKAGES <URL> <SHA512> <URL> <SHA512> ...]
13
+ )
14
+ ```
15
+
16
+ ## Parameters
17
+ ### MSYS_ROOT_VAR
18
+ An out-variable that will be set to the path to MSYS2.
19
+
20
+ ### PACKAGES
21
+ A list of packages to acquire in msys.
22
+
23
+ To ensure a package is available: `vcpkg_acquire_msys(MSYS_ROOT PACKAGES make automake1.16)`
24
+
25
+ ### NO_DEFAULT_PACKAGES
26
+ Exclude the normal base packages.
27
+
28
+ The list of base packages includes: bash, coreutils, sed, grep, gawk, gzip, diffutils, make, and pkg-config
29
+
30
+ ### DIRECT_PACKAGES
31
+ A list of URL/SHA512 pairs to acquire in msys.
32
+
33
+ This parameter can be used by a port to privately extend the list of msys packages to be acquired.
34
+ The URLs can be found on the msys2 website[1] and should be a direct archive link:
35
+
36
+ https://repo.msys2.org/mingw/i686/mingw-w64-i686-gettext-0.19.8.1-9-any.pkg.tar.zst
37
+
38
+ [1] https://packages.msys2.org/search
39
+
40
+ ## Notes
41
+ A call to `vcpkg_acquire_msys` will usually be followed by a call to `bash.exe`:
42
+ ```cmake
43
+ vcpkg_acquire_msys(MSYS_ROOT)
44
+ set(BASH ${MSYS_ROOT}/usr/bin/bash.exe)
45
+
46
+ vcpkg_execute_required_process(
47
+ COMMAND ${BASH} --noprofile --norc "${CMAKE_CURRENT_LIST_DIR}\\build.sh"
48
+ WORKING_DIRECTORY ${CURRENT_BUILDTREES_DIR}/${TARGET_TRIPLET}-rel
49
+ LOGNAME build-${TARGET_TRIPLET}-rel
50
+ )
51
+ ```
52
+
53
+ ## Examples
54
+
55
+ * [ffmpeg](https://github.com/Microsoft/vcpkg/blob/master/ports/ffmpeg/portfile.cmake)
56
+ * [icu](https://github.com/Microsoft/vcpkg/blob/master/ports/icu/portfile.cmake)
57
+ * [libvpx](https://github.com/Microsoft/vcpkg/blob/master/ports/libvpx/portfile.cmake)
58
+
59
+ ## Source
60
+ [scripts/cmake/vcpkg\_acquire\_msys.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_acquire_msys.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_add_to_path.md ADDED
@@ -0,0 +1,27 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_add_to_path
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_add_to_path.md).
4
+
5
+ Add a directory or directories to the PATH environment variable
6
+
7
+ ```cmake
8
+ vcpkg_add_to_path([PREPEND] [<path>...])
9
+ ```
10
+
11
+ `vcpkg_add_to_path` adds all of the paths passed to it to the PATH environment variable.
12
+ If PREPEND is passed, then those paths are prepended to the PATH environment variable,
13
+ so that they are searched first; otherwise, those paths are appended, so they are
14
+ searched after the paths which are already in the environment variable.
15
+
16
+ The paths are added in the order received, so that the first path is always searched
17
+ before a later path.
18
+
19
+ If no paths are passed, then nothing will be done.
20
+
21
+ ## Examples:
22
+ * [curl](https://github.com/Microsoft/vcpkg/blob/master/ports/curl/portfile.cmake#L75)
23
+ * [folly](https://github.com/Microsoft/vcpkg/blob/master/ports/folly/portfile.cmake#L15)
24
+ * [z3](https://github.com/Microsoft/vcpkg/blob/master/ports/z3/portfile.cmake#L13)
25
+
26
+ ## Source
27
+ [scripts/cmake/vcpkg\_add\_to\_path.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_add_to_path.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_apply_patches.md ADDED
@@ -0,0 +1,18 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_apply_patches
2
+
3
+ **This function has been deprecated in favor of the `PATCHES` argument to [`vcpkg_from_github()`](vcpkg_from_github.md) et al.**
4
+
5
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_apply_patches.md).
6
+
7
+ Apply a set of patches to a source tree.
8
+
9
+ ```cmake
10
+ vcpkg_apply_patches(
11
+ SOURCE_PATH <${SOURCE_PATH}>
12
+ [QUIET]
13
+ PATCHES <patch1.patch>...
14
+ )
15
+ ```
16
+
17
+ ## Source
18
+ [scripts/cmake/vcpkg\_apply\_patches.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_apply_patches.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_backup_restore_env_vars.md ADDED
@@ -0,0 +1,26 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_backup_restore_env_vars
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_backup_restore_env_vars.md).
4
+
5
+ Backup or restore the environment variables
6
+
7
+ ## Usage:
8
+ ```cmake
9
+ vcpkg_backup_env_variables(VARS [<environment-variable>...])
10
+ vcpkg_restore_env_variables(VARS [<environment-variable>...])
11
+ ```
12
+
13
+ ### VARS
14
+ The variables to back up or restore.
15
+ These are placed in the parent scope, so you must backup and restore
16
+ from the same scope.
17
+
18
+ ## Notes
19
+ One must always call `vcpkg_backup_env_variables` before
20
+ `vcpkg_restore_env_variables`; however, `vcpkg_restore_env_variables`
21
+ does not change the back up variables, and so you may call `restore`
22
+ multiple times for one `backup`.
23
+
24
+
25
+ ## Source
26
+ [scripts/cmake/vcpkg\_backup\_restore\_env\_vars.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_backup_restore_env_vars.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_cmake.md ADDED
@@ -0,0 +1,38 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_cmake
2
+
3
+ **This function has been deprecated in favor of [`vcpkg_cmake_build`](ports/vcpkg-cmake/vcpkg_cmake_build.md) from the vcpkg-cmake port.**
4
+
5
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_cmake.md).
6
+
7
+ Build a cmake project.
8
+
9
+ ## Usage:
10
+ ```cmake
11
+ vcpkg_build_cmake([DISABLE_PARALLEL] [TARGET <target>])
12
+ ```
13
+
14
+ ## Parameters:
15
+ ### DISABLE_PARALLEL
16
+ The underlying buildsystem will be instructed to not parallelize
17
+
18
+ ### TARGET
19
+ The target passed to the cmake build command (`cmake --build . --target <target>`). If not specified, no target will
20
+ be passed.
21
+
22
+ ### ADD_BIN_TO_PATH
23
+ Adds the appropriate Release and Debug `bin` directories to the path during the build such that executables can run against the in-tree DLLs.
24
+
25
+ ## Notes:
26
+ This command should be preceded by a call to [`vcpkg_configure_cmake()`](vcpkg_configure_cmake.md).
27
+ You can use the alias [`vcpkg_install_cmake()`](vcpkg_configure_cmake.md) function if your CMake script supports the
28
+ "install" target
29
+
30
+ ## Examples:
31
+
32
+ * [zlib](https://github.com/Microsoft/vcpkg/blob/master/ports/zlib/portfile.cmake)
33
+ * [cpprestsdk](https://github.com/Microsoft/vcpkg/blob/master/ports/cpprestsdk/portfile.cmake)
34
+ * [poco](https://github.com/Microsoft/vcpkg/blob/master/ports/poco/portfile.cmake)
35
+ * [opencv](https://github.com/Microsoft/vcpkg/blob/master/ports/opencv/portfile.cmake)
36
+
37
+ ## Source
38
+ [scripts/cmake/vcpkg\_build\_cmake.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_cmake.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_make.md ADDED
@@ -0,0 +1,57 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_make
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_make.md).
4
+
5
+ Build a linux makefile project.
6
+
7
+ ## Usage:
8
+ ```cmake
9
+ vcpkg_build_make([BUILD_TARGET <target>]
10
+ [INSTALL_TARGET <target>]
11
+ [ADD_BIN_TO_PATH]
12
+ [ENABLE_INSTALL]
13
+ [MAKEFILE <makefileName>]
14
+ [LOGFILE_ROOT <logfileroot>]
15
+ [DISABLE_PARALLEL]
16
+ [SUBPATH <path>])
17
+ ```
18
+
19
+ ### BUILD_TARGET
20
+ The target passed to the make build command (`./make <target>`). If not specified, the 'all' target will
21
+ be passed.
22
+
23
+ ### INSTALL_TARGET
24
+ The target passed to the make build command (`./make <target>`) if `ENABLE_INSTALL` is used. Defaults to 'install'.
25
+
26
+ ### ADD_BIN_TO_PATH
27
+ Adds the appropriate Release and Debug `bin\` directories to the path during the build such that executables can run against the in-tree DLLs.
28
+
29
+ ### ENABLE_INSTALL
30
+ IF the port supports the install target use vcpkg_install_make() instead of vcpkg_build_make()
31
+
32
+ ### MAKEFILE
33
+ Specifies the Makefile as a relative path from the root of the sources passed to `vcpkg_configure_make()`
34
+
35
+ ### LOGFILE_ROOT
36
+ Specifies a log file prefix.
37
+
38
+ ### DISABLE_PARALLEL
39
+ The underlying buildsystem will be instructed to not parallelize
40
+
41
+ ### SUBPATH
42
+ Additional subdir to invoke make in. Useful if only parts of a port should be built.
43
+
44
+ ## Notes:
45
+ This command should be preceded by a call to [`vcpkg_configure_make()`](vcpkg_configure_make.md).
46
+ You can use the alias [`vcpkg_install_make()`](vcpkg_install_make.md) function if your makefile supports the
47
+ "install" target
48
+
49
+ ## Examples
50
+
51
+ * [x264](https://github.com/Microsoft/vcpkg/blob/master/ports/x264/portfile.cmake)
52
+ * [tcl](https://github.com/Microsoft/vcpkg/blob/master/ports/tcl/portfile.cmake)
53
+ * [freexl](https://github.com/Microsoft/vcpkg/blob/master/ports/freexl/portfile.cmake)
54
+ * [libosip2](https://github.com/Microsoft/vcpkg/blob/master/ports/libosip2/portfile.cmake)
55
+
56
+ ## Source
57
+ [scripts/cmake/vcpkg\_build\_make.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_make.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_msbuild.md ADDED
@@ -0,0 +1,66 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_msbuild
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_msbuild.md).
4
+
5
+ Build a msbuild-based project. Deprecated in favor of `vcpkg_install_msbuild()`.
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_build_msbuild(
10
+ PROJECT_PATH <${SOURCE_PATH}/port.sln>
11
+ [RELEASE_CONFIGURATION <Release>]
12
+ [DEBUG_CONFIGURATION <Debug>]
13
+ [TARGET <Build>]
14
+ [TARGET_PLATFORM_VERSION <10.0.15063.0>]
15
+ [PLATFORM <${TRIPLET_SYSTEM_ARCH}>]
16
+ [PLATFORM_TOOLSET <${VCPKG_PLATFORM_TOOLSET}>]
17
+ [OPTIONS </p:ZLIB_INCLUDE_PATH=X>...]
18
+ [OPTIONS_RELEASE </p:ZLIB_LIB=X>...]
19
+ [OPTIONS_DEBUG </p:ZLIB_LIB=X>...]
20
+ [USE_VCPKG_INTEGRATION]
21
+ )
22
+ ```
23
+
24
+ ## Parameters
25
+ ### USE_VCPKG_INTEGRATION
26
+ Apply the normal `integrate install` integration for building the project.
27
+
28
+ By default, projects built with this command will not automatically link libraries or have header paths set.
29
+
30
+ ### PROJECT_PATH
31
+ The path to the solution (`.sln`) or project (`.vcxproj`) file.
32
+
33
+ ### RELEASE_CONFIGURATION
34
+ The configuration (``/p:Configuration`` msbuild parameter) used for Release builds.
35
+
36
+ ### DEBUG_CONFIGURATION
37
+ The configuration (``/p:Configuration`` msbuild parameter)
38
+ used for Debug builds.
39
+
40
+ ### TARGET_PLATFORM_VERSION
41
+ The WindowsTargetPlatformVersion (``/p:WindowsTargetPlatformVersion`` msbuild parameter)
42
+
43
+ ### TARGET
44
+ The MSBuild target to build. (``/t:<TARGET>``)
45
+
46
+ ### PLATFORM
47
+ The platform (``/p:Platform`` msbuild parameter) used for the build.
48
+
49
+ ### PLATFORM_TOOLSET
50
+ The platform toolset (``/p:PlatformToolset`` msbuild parameter) used for the build.
51
+
52
+ ### OPTIONS
53
+ Additional options passed to msbuild for all builds.
54
+
55
+ ### OPTIONS_RELEASE
56
+ Additional options passed to msbuild for Release builds. These are in addition to `OPTIONS`.
57
+
58
+ ### OPTIONS_DEBUG
59
+ Additional options passed to msbuild for Debug builds. These are in addition to `OPTIONS`.
60
+
61
+ ## Examples
62
+
63
+ * [chakracore](https://github.com/Microsoft/vcpkg/blob/master/ports/chakracore/portfile.cmake)
64
+
65
+ ## Source
66
+ [scripts/cmake/vcpkg\_build\_msbuild.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_msbuild.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_ninja.md ADDED
@@ -0,0 +1,19 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_ninja
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_ninja.md).
4
+
5
+ Build a ninja project
6
+
7
+ ## Usage:
8
+ ```cmake
9
+ vcpkg_build_ninja(
10
+ [TARGETS <target>...]
11
+ )
12
+ ```
13
+
14
+ ## Parameters:
15
+ ### TARGETS
16
+ Only build the specified targets.
17
+
18
+ ## Source
19
+ [scripts/cmake/vcpkg\_build\_ninja.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_ninja.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_nmake.md ADDED
@@ -0,0 +1,72 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_nmake
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_nmake.md).
4
+
5
+ Build a msvc makefile project.
6
+
7
+ ## Usage:
8
+ ```cmake
9
+ vcpkg_build_nmake(
10
+ SOURCE_PATH <${SOURCE_PATH}>
11
+ [NO_DEBUG]
12
+ [ENABLE_INSTALL]
13
+ [TARGET <all>]
14
+ [PROJECT_SUBPATH <${SUBPATH}>]
15
+ [PROJECT_NAME <${MAKEFILE_NAME}>]
16
+ [PRERUN_SHELL <${SHELL_PATH}>]
17
+ [PRERUN_SHELL_DEBUG <${SHELL_PATH}>]
18
+ [PRERUN_SHELL_RELEASE <${SHELL_PATH}>]
19
+ [OPTIONS <-DUSE_THIS_IN_ALL_BUILDS=1>...]
20
+ [OPTIONS_RELEASE <-DOPTIMIZE=1>...]
21
+ [OPTIONS_DEBUG <-DDEBUGGABLE=1>...]
22
+ [TARGET <target>])
23
+ ```
24
+
25
+ ## Parameters
26
+ ### SOURCE_PATH
27
+ Specifies the directory containing the source files.
28
+ By convention, this is usually set in the portfile as the variable `SOURCE_PATH`.
29
+
30
+ ### PROJECT_SUBPATH
31
+ Specifies the sub directory containing the `makefile.vc`/`makefile.mak`/`makefile.msvc` or other msvc makefile.
32
+
33
+ ### PROJECT_NAME
34
+ Specifies the name of msvc makefile name.
35
+ Default is `makefile.vc`
36
+
37
+ ### ENABLE_INSTALL
38
+ Install binaries after build.
39
+
40
+ ### PRERUN_SHELL
41
+ Script that needs to be called before build
42
+
43
+ ### PRERUN_SHELL_DEBUG
44
+ Script that needs to be called before debug build
45
+
46
+ ### PRERUN_SHELL_RELEASE
47
+ Script that needs to be called before release build
48
+
49
+ ### OPTIONS
50
+ Additional options passed to generate during the generation.
51
+
52
+ ### OPTIONS_RELEASE
53
+ Additional options passed to generate during the Release generation. These are in addition to `OPTIONS`.
54
+
55
+ ### OPTIONS_DEBUG
56
+ Additional options passed to generate during the Debug generation. These are in addition to `OPTIONS`.
57
+
58
+ ### TARGET
59
+ The target passed to the nmake build command (`nmake/nmake install`). If not specified, no target will
60
+ be passed.
61
+
62
+ ## Notes:
63
+ You can use the alias [`vcpkg_install_nmake()`](vcpkg_install_nmake.md) function if your makefile supports the
64
+ "install" target
65
+
66
+ ## Examples
67
+
68
+ * [tcl](https://github.com/Microsoft/vcpkg/blob/master/ports/tcl/portfile.cmake)
69
+ * [freexl](https://github.com/Microsoft/vcpkg/blob/master/ports/freexl/portfile.cmake)
70
+
71
+ ## Source
72
+ [scripts/cmake/vcpkg\_build\_nmake.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_nmake.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_build_qmake.md ADDED
@@ -0,0 +1,12 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_build_qmake
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_build_qmake.md).
4
+
5
+ Build a qmake-based project, previously configured using vcpkg_configure_qmake.
6
+
7
+ ```cmake
8
+ vcpkg_build_qmake()
9
+ ```
10
+
11
+ ## Source
12
+ [scripts/cmake/vcpkg\_build\_qmake.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_build_qmake.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_buildpath_length_warning.md ADDED
@@ -0,0 +1,16 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_buildpath_length_warning
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_buildpath_length_warning.md).
4
+
5
+ Warns the user if their vcpkg installation path might be too long for the package they're installing.
6
+
7
+ ```cmake
8
+ vcpkg_buildpath_length_warning(<N>)
9
+ ```
10
+
11
+ `vcpkg_buildpath_length_warning` warns the user if the number of bytes in the
12
+ path to `buildtrees` is bigger than `N`. Note that this is simply a warning,
13
+ and isn't relied on for correctness.
14
+
15
+ ## Source
16
+ [scripts/cmake/vcpkg\_buildpath\_length\_warning.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_buildpath_length_warning.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_check_features.md ADDED
@@ -0,0 +1,136 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_check_features
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_check_features.md).
4
+ Check if one or more features are a part of a package installation.
5
+
6
+ ```cmake
7
+ vcpkg_check_features(
8
+ OUT_FEATURE_OPTIONS <out-var>
9
+ [PREFIX <prefix>]
10
+ [FEATURES
11
+ [<feature-name> <feature-var>]...
12
+ ]
13
+ [INVERTED_FEATURES
14
+ [<feature-name> <feature-var>]...
15
+ ]
16
+ )
17
+ ```
18
+
19
+ The `<out-var>` should be set to `FEATURE_OPTIONS` by convention.
20
+
21
+ `vcpkg_check_features()` will:
22
+
23
+ - for each `<feature-name>` passed in `FEATURES`:
24
+ - if the feature is set, add `-D<feature-var>=ON` to `<out-var>`,
25
+ and set `<prefix>_<feature-var>` to ON.
26
+ - if the feature is not set, add `-D<feature-var>=OFF` to `<out-var>`,
27
+ and set `<prefix>_<feature-var>` to OFF.
28
+ - for each `<feature-name>` passed in `INVERTED_FEATURES`:
29
+ - if the feature is set, add `-D<feature-var>=OFF` to `<out-var>`,
30
+ and set `<prefix>_<feature-var>` to OFF.
31
+ - if the feature is not set, add `-D<feature-var>=ON` to `<out-var>`,
32
+ and set `<prefix>_<feature-var>` to ON.
33
+
34
+ If `<prefix>` is not passed, then the feature vars set are simply `<feature-var>`,
35
+ not `_<feature-var>`.
36
+
37
+ If `INVERTED_FEATURES` is not passed, then the `FEATURES` keyword is optional.
38
+ This behavior is deprecated.
39
+
40
+ If the same `<feature-var>` is passed multiple times,
41
+ then `vcpkg_check_features` will cause a fatal error,
42
+ since that is a bug.
43
+
44
+ ## Examples
45
+
46
+ ### Example 1: Regular features
47
+
48
+ ```cmake
49
+ $ ./vcpkg install mimalloc[asm,secure]
50
+
51
+ # ports/mimalloc/portfile.cmake
52
+ vcpkg_check_features(OUT_FEATURE_OPTIONS FEATURE_OPTIONS
53
+ FEATURES
54
+ asm MI_SEE_ASM
55
+ override MI_OVERRIDE
56
+ secure MI_SECURE
57
+ )
58
+
59
+ vcpkg_cmake_configure(
60
+ SOURCE_PATH ${SOURCE_PATH}
61
+ OPTIONS
62
+ # Expands to "-DMI_SEE_ASM=ON;-DMI_OVERRIDE=OFF;-DMI_SECURE=ON"
63
+ ${FEATURE_OPTIONS}
64
+ )
65
+ ```
66
+
67
+ ### Example 2: Inverted features
68
+
69
+ ```cmake
70
+ $ ./vcpkg install cpprestsdk[websockets]
71
+
72
+ # ports/cpprestsdk/portfile.cmake
73
+ vcpkg_check_features(
74
+ INVERTED_FEATURES
75
+ brotli CPPREST_EXCLUDE_BROTLI
76
+ websockets CPPREST_EXCLUDE_WEBSOCKETS
77
+ )
78
+
79
+ vcpkg_cmake_configure(
80
+ SOURCE_PATH ${SOURCE_PATH}
81
+ OPTIONS
82
+ # Expands to "-DCPPREST_EXCLUDE_BROTLI=ON;-DCPPREST_EXCLUDE_WEBSOCKETS=OFF"
83
+ ${FEATURE_OPTIONS}
84
+ )
85
+ ```
86
+
87
+ ### Example 3: Set multiple options for same feature
88
+
89
+ ```cmake
90
+ $ ./vcpkg install pcl[cuda]
91
+
92
+ # ports/pcl/portfile.cmake
93
+ vcpkg_check_features(
94
+ FEATURES
95
+ cuda WITH_CUDA
96
+ cuda BUILD_CUDA
97
+ cuda BUILD_GPU
98
+ )
99
+
100
+ vcpkg_cmake_configure(
101
+ SOURCE_PATH ${SOURCE_PATH}
102
+ OPTIONS
103
+ # Expands to "-DWITH_CUDA=ON;-DBUILD_CUDA=ON;-DBUILD_GPU=ON"
104
+ ${FEATURE_OPTIONS}
105
+ )
106
+ ```
107
+
108
+ ### Example 4: Use regular and inverted features
109
+
110
+ ```cmake
111
+ $ ./vcpkg install rocksdb[tbb]
112
+
113
+ # ports/rocksdb/portfile.cmake
114
+ vcpkg_check_features(
115
+ FEATURES
116
+ tbb WITH_TBB
117
+ INVERTED_FEATURES
118
+ tbb ROCKSDB_IGNORE_PACKAGE_TBB
119
+ )
120
+
121
+ vcpkg_cmake_configure(
122
+ SOURCE_PATH ${SOURCE_PATH}
123
+ OPTIONS
124
+ # Expands to "-DWITH_TBB=ON;-DROCKSDB_IGNORE_PACKAGE_TBB=OFF"
125
+ ${FEATURE_OPTIONS}
126
+ )
127
+ ```
128
+
129
+ ## Examples in portfiles
130
+
131
+ * [cpprestsdk](https://github.com/microsoft/vcpkg/blob/master/ports/cpprestsdk/portfile.cmake)
132
+ * [pcl](https://github.com/microsoft/vcpkg/blob/master/ports/pcl/portfile.cmake)
133
+ * [rocksdb](https://github.com/microsoft/vcpkg/blob/master/ports/rocksdb/portfile.cmake)
134
+
135
+ ## Source
136
+ [scripts/cmake/vcpkg\_check\_features.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_check_features.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_check_linkage.md ADDED
@@ -0,0 +1,38 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_check_linkage
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_check_linkage.md).
4
+
5
+ Asserts the available library and CRT linkage options for the port.
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_check_linkage(
10
+ [ONLY_STATIC_LIBRARY | ONLY_DYNAMIC_LIBRARY]
11
+ [ONLY_STATIC_CRT | ONLY_DYNAMIC_CRT]
12
+ )
13
+ ```
14
+
15
+ ## Parameters
16
+ ### ONLY_STATIC_LIBRARY
17
+ Indicates that this port can only be built with static library linkage.
18
+
19
+ Note: If the user requested a dynamic build ONLY_STATIC_LIBRARY will result in a note being printed, not a fatal error.
20
+
21
+ ### ONLY_DYNAMIC_LIBRARY
22
+ Indicates that this port can only be built with dynamic/shared library linkage.
23
+
24
+ ### ONLY_STATIC_CRT
25
+ Indicates that this port can only be built with static CRT linkage.
26
+
27
+ ### ONLY_DYNAMIC_CRT
28
+ Indicates that this port can only be built with dynamic/shared CRT linkage.
29
+
30
+ ## Notes
31
+ This command will either alter the settings for `VCPKG_LIBRARY_LINKAGE` or fail, depending on what was requested by the user versus what the library supports.
32
+
33
+ ## Examples
34
+
35
+ * [abseil](https://github.com/Microsoft/vcpkg/blob/master/ports/abseil/portfile.cmake)
36
+
37
+ ## Source
38
+ [scripts/cmake/vcpkg\_check\_linkage.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_check_linkage.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_clean_executables_in_bin.md ADDED
@@ -0,0 +1,25 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_clean_executables_in_bin
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_clean_executables_in_bin.md).
4
+
5
+ Remove specified executables found in `${CURRENT_PACKAGES_DIR}/bin` and `${CURRENT_PACKAGES_DIR}/debug/bin`. If, after all specified executables have been removed, and the `bin` and `debug/bin` directories are empty, then also delete `bin` and `debug/bin` directories.
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_clean_executables_in_bin(
10
+ FILE_NAMES <file1>...
11
+ )
12
+ ```
13
+
14
+ ## Parameters
15
+ ### FILE_NAMES
16
+ A list of executable filenames without extension.
17
+
18
+ ## Notes
19
+ Generally, there is no need to call this function manually. Instead, pass an extra `AUTO_CLEAN` argument when calling `vcpkg_copy_tools`.
20
+
21
+ ## Examples
22
+ * [czmq](https://github.com/microsoft/vcpkg/blob/master/ports/czmq/portfile.cmake)
23
+
24
+ ## Source
25
+ [scripts/cmake/vcpkg\_clean\_executables\_in\_bin.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_clean_executables_in_bin.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_clean_msbuild.md ADDED
@@ -0,0 +1,17 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_clean_msbuild
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_clean_msbuild.md).
4
+
5
+ Clean intermediate files generated by `vcpkg_install_msbuild()`.
6
+
7
+ ## Usage
8
+ ```cmake
9
+ vcpkg_clean_msbuild()
10
+ ```
11
+
12
+ ## Examples
13
+
14
+ * [python3](https://github.com/Microsoft/vcpkg/blob/master/ports/python3/portfile.cmake)
15
+
16
+ ## Source
17
+ [scripts/cmake/vcpkg\_clean\_msbuild.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_clean_msbuild.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_common_definitions.md ADDED
@@ -0,0 +1,36 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_common_definitions
2
+
3
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_common_definitions.md).
4
+
5
+ This file defines the following variables which are commonly needed or used in portfiles:
6
+
7
+ ```cmake
8
+ VCPKG_TARGET_IS_<target> with <target> being one of the following: WINDOWS, UWP, MINGW, LINUX, OSX, ANDROID, FREEBSD, OPENBSD. only defined if <target>
9
+ VCPKG_HOST_IS_<host> with <host> being one of the following: WINDOWS, LINUX, OSX, FREEBSD, OPENBSD. only defined if <host>
10
+ VCPKG_HOST_PATH_SEPARATOR Host specific path separator (USAGE: "<something>${VCPKG_HOST_PATH_SEPARATOR}<something>"; only use and pass variables with VCPKG_HOST_PATH_SEPARATOR within "")
11
+ VCPKG_HOST_EXECUTABLE_SUFFIX executable suffix of the host
12
+ VCPKG_TARGET_EXECUTABLE_SUFFIX executable suffix of the target
13
+ VCPKG_HOST_BUNDLE_SUFFIX bundle suffix of the host
14
+ VCPKG_TARGET_BUNDLE_SUFFIX bundle suffix of the target
15
+ VCPKG_TARGET_STATIC_LIBRARY_PREFIX static library prefix for target (same as CMAKE_STATIC_LIBRARY_PREFIX)
16
+ VCPKG_TARGET_STATIC_LIBRARY_SUFFIX static library suffix for target (same as CMAKE_STATIC_LIBRARY_SUFFIX)
17
+ VCPKG_TARGET_SHARED_LIBRARY_PREFIX shared library prefix for target (same as CMAKE_SHARED_LIBRARY_PREFIX)
18
+ VCPKG_TARGET_SHARED_LIBRARY_SUFFIX shared library suffix for target (same as CMAKE_SHARED_LIBRARY_SUFFIX)
19
+ VCPKG_TARGET_IMPORT_LIBRARY_PREFIX import library prefix for target (same as CMAKE_IMPORT_LIBRARY_PREFIX)
20
+ VCPKG_TARGET_IMPORT_LIBRARY_SUFFIX import library suffix for target (same as CMAKE_IMPORT_LIBRARY_SUFFIX)
21
+ VCPKG_FIND_LIBRARY_PREFIXES target dependent prefixes used for find_library calls in portfiles
22
+ VCPKG_FIND_LIBRARY_SUFFIXES target dependent suffixes used for find_library calls in portfiles
23
+ VCPKG_SYSTEM_LIBRARIES list of libraries are provide by the toolchain and are not managed by vcpkg
24
+ TARGET_TRIPLET the name of the current triplet to build for
25
+ CURRENT_INSTALLED_DIR the absolute path to the installed files for the current triplet
26
+ HOST_TRIPLET the name of the triplet corresponding to the host
27
+ CURRENT_HOST_INSTALLED_DIR the absolute path to the installed files for the host triplet
28
+ VCPKG_CROSSCOMPILING Whether vcpkg is cross-compiling: in other words, whether TARGET_TRIPLET and HOST_TRIPLET are different
29
+ ```
30
+
31
+ CMAKE_STATIC_LIBRARY_(PREFIX|SUFFIX), CMAKE_SHARED_LIBRARY_(PREFIX|SUFFIX) and CMAKE_IMPORT_LIBRARY_(PREFIX|SUFFIX) are defined for the target
32
+ Furthermore the variables CMAKE_FIND_LIBRARY_(PREFIXES|SUFFIXES) are also defined for the target so that
33
+ portfiles are able to use find_library calls to discover dependent libraries within the current triplet for ports.
34
+
35
+ ## Source
36
+ [scripts/cmake/vcpkg\_common\_definitions.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_common_definitions.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_configure_cmake.md ADDED
@@ -0,0 +1,87 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_configure_cmake
2
+
3
+ **This function has been deprecated in favor of [`vcpkg_cmake_configure`](ports/vcpkg-cmake/vcpkg_cmake_configure.md) from the vcpkg-cmake port.**
4
+
5
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_configure_cmake.md).
6
+
7
+ Configure CMake for Debug and Release builds of a project.
8
+
9
+ ## Usage
10
+ ```cmake
11
+ vcpkg_configure_cmake(
12
+ SOURCE_PATH <${SOURCE_PATH}>
13
+ [PREFER_NINJA]
14
+ [DISABLE_PARALLEL_CONFIGURE]
15
+ [NO_CHARSET_FLAG]
16
+ [GENERATOR <"NMake Makefiles">]
17
+ [OPTIONS <-DUSE_THIS_IN_ALL_BUILDS=1>...]
18
+ [OPTIONS_RELEASE <-DOPTIMIZE=1>...]
19
+ [OPTIONS_DEBUG <-DDEBUGGABLE=1>...]
20
+ [MAYBE_UNUSED_VARIABLES <OPTION_NAME>...]
21
+ )
22
+ ```
23
+
24
+ ## Parameters
25
+ ### SOURCE_PATH
26
+ Specifies the directory containing the `CMakeLists.txt`.
27
+ By convention, this is usually set in the portfile as the variable `SOURCE_PATH`.
28
+
29
+ ### PREFER_NINJA
30
+ Indicates that, when available, Vcpkg should use Ninja to perform the build.
31
+ This should be specified unless the port is known to not work under Ninja.
32
+
33
+ ### DISABLE_PARALLEL_CONFIGURE
34
+ Disables running the CMake configure step in parallel.
35
+ This is needed for libraries which write back into their source directory during configure.
36
+
37
+ This also disables CMAKE_DISABLE_SOURCE_CHANGES.
38
+
39
+ ### NO_CHARSET_FLAG
40
+ Disables passing `utf-8` as the default character set to `CMAKE_C_FLAGS` and `CMAKE_CXX_FLAGS`.
41
+
42
+ This is needed for libraries that set their own source code's character set.
43
+
44
+ ### GENERATOR
45
+ Specifies the precise generator to use.
46
+
47
+ This is useful if some project-specific buildsystem has been wrapped in a cmake script that won't perform an actual build.
48
+ If used for this purpose, it should be set to `"NMake Makefiles"`.
49
+
50
+ ### OPTIONS
51
+ Additional options passed to CMake during the configuration.
52
+
53
+ ### OPTIONS_RELEASE
54
+ Additional options passed to CMake during the Release configuration. These are in addition to `OPTIONS`.
55
+
56
+ ### OPTIONS_DEBUG
57
+ Additional options passed to CMake during the Debug configuration. These are in addition to `OPTIONS`.
58
+
59
+ ### MAYBE_UNUSED_VARIABLES
60
+ Any CMake variables which are explicitly passed in, but which may not be used on all platforms.
61
+ For example:
62
+ ```cmake
63
+ vcpkg_cmake_configure(
64
+ ...
65
+ OPTIONS
66
+ -DBUILD_EXAMPLE=OFF
67
+ ...
68
+ MAYBE_UNUSED_VARIABLES
69
+ BUILD_EXAMPLE
70
+ )
71
+ ```
72
+
73
+ ### LOGNAME
74
+ Name of the log to write the output of the configure call to.
75
+
76
+ ## Notes
77
+ This command supplies many common arguments to CMake. To see the full list, examine the source.
78
+
79
+ ## Examples
80
+
81
+ * [zlib](https://github.com/Microsoft/vcpkg/blob/master/ports/zlib/portfile.cmake)
82
+ * [cpprestsdk](https://github.com/Microsoft/vcpkg/blob/master/ports/cpprestsdk/portfile.cmake)
83
+ * [poco](https://github.com/Microsoft/vcpkg/blob/master/ports/poco/portfile.cmake)
84
+ * [opencv](https://github.com/Microsoft/vcpkg/blob/master/ports/opencv/portfile.cmake)
85
+
86
+ ## Source
87
+ [scripts/cmake/vcpkg\_configure\_cmake.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_configure_cmake.cmake)
third-party/DPVO/Pangolin/scripts/vcpkg/docs/maintainers/vcpkg_configure_gn.md ADDED
@@ -0,0 +1,34 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # vcpkg_configure_gn
2
+
3
+ **This function has been deprecated in favor of [`vcpkg_gn_configure`](ports/vcpkg-gn/vcpkg_gn_configure.md) from the vcpkg-gn port.**
4
+
5
+ The latest version of this document lives in the [vcpkg repo](https://github.com/Microsoft/vcpkg/blob/master/docs/maintainers/vcpkg_configure_gn.md).
6
+
7
+ Generate Ninja (GN) targets
8
+
9
+ ## Usage:
10
+ ```cmake
11
+ vcpkg_configure_gn(
12
+ SOURCE_PATH <SOURCE_PATH>
13
+ [OPTIONS <OPTIONS>]
14
+ [OPTIONS_DEBUG <OPTIONS_DEBUG>]
15
+ [OPTIONS_RELEASE <OPTIONS_RELEASE>]
16
+ )
17
+ ```
18
+
19
+ ## Parameters:
20
+ ### SOURCE_PATH (required)
21
+ The path to the GN project.
22
+
23
+ ### OPTIONS
24
+ Options to be passed to both the debug and release targets.
25
+ Note: Must be provided as a space-separated string.
26
+
27
+ ### OPTIONS_DEBUG (space-separated string)
28
+ Options to be passed to the debug target.
29
+
30
+ ### OPTIONS_RELEASE (space-separated string)
31
+ Options to be passed to the release target.
32
+
33
+ ## Source
34
+ [scripts/cmake/vcpkg\_configure\_gn.cmake](https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_configure_gn.cmake)