* Extract vcpkg_extract_archive from vcpkg_find_acquire_program.
* Extract vcpkg_download_sourceforge from vcpkg_from_sourceforge.
This allows vcpkg_find_acquire_program to download from SourceForge without needing to temporarily change _VCPKG_EDITABLE.
* Use whether a URI is known for an entity to decide whether to downloads it rather than checking a separate supported_on_unix boolean.
* Add unparsed arguments check to vcpkg_extract_archive
* Hook up z-applocal, work started by @vicroms.
* Fix spelling of utf8
* Use standard warning formats.
* Don't get in the way of stdout.
* Don't try to Applocal deploy if the linker does not run.
* Make VcpkgUseBuiltInApplocalDeps docs a bit nicer.
* Change to (experimental) prefix.
* Add an X.
* [vcpkg_configure_make] fix case sensitive comparison in PATH system dir search
* Fixes after code review
---------
Co-authored-by: Victor NIVET <vnivet@invoke.fr>
* [libmysql] Update to 8.0.34
* [libmysql] Fix deps
* [libmysql] Fix deps, cont.
* WIP
* WIP
* [libmysql] Don't wrap downstream Find modules
Downstream Find modules are not standardized and cannot be wrapped
reliably. By moving the legacy wrapper behaviour to a config module,
we can catch those users which were relying on the old usage, and
display the instructions for migrating to the canonical unofficial
usage.
* [libmysql] Cross build stuff
* [libmysql] Cross build stuff
* [libmysql] Cross build stuff
Results from build: https://dev.azure.com/vcpkg/public/_build/results?buildId=95281
PASSING, REMOVE FROM FAIL LIST: qcoro:x64-osx (/Users/vagrant/Data/work/2/s/scripts/azure-pipelines/../ci.baseline.txt).
Caused by https://github.com/microsoft/vcpkg/pull/33273
The comment says that it's an ICE but it passed in CI; this might be a form of intermittent compiler crash. If we get a failure next time we should change this to skip instead.
From https://dev.azure.com/vcpkg/public/_build/results?buildId=94820
REGRESSION: caffe2:arm64-windows is marked as fail but one dependency is not supported for arm64-windows.
REGRESSION: gtk:x64-windows-static is marked as fail but one dependency is not supported for x64-windows-static.
Fixed by https://github.com/microsoft/vcpkg/pull/33999
REGRESSION: omplapp:arm-neon-android failed with BUILD_FAILED. If expected, add omplapp:arm-neon-android=fail to /vcpkg/scripts/azure-pipelines/../ci.baseline.txt.
Previously blocked by:
PASSING, REMOVE FROM FAIL LIST: assimp:arm-neon-android (/vcpkg/scripts/azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: clblast:arm-neon-android (/vcpkg/scripts/azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: clblast:arm64-android (/vcpkg/scripts/azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: clblast:x64-android (/vcpkg/scripts/azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: openvdb:x64-windows-static (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: openvdb:x64-windows-static-md (C:\a\2\s\scripts\azure-pipelines/../ci.baseline.txt).
* Add libcoro 0.7
* Update CI baseline
* Add "supports": "!windows"
* Update CI baseline
* Remove unneeded vcpkg-cmake-config dependency
* Update CI baseline
* Disable x64-linux and x64-osx in ci.baseline.txt
* Apply code review suggestions
* Update CI baseline
* Add patch to disable git config
* Update CI baseline
* Fix patch
* Update CI baseline
* Allow shared library builds
* Update CI baseline
* Update libcoro to version 0.8
* Update CI baseline
* Update CI baseline
* Fix line endings
* Update CI baseline
* Fix hash
* Update CI baseline
* Update version database
* Force rerun of CI pipeline
* Update to libcoro 0.9
* Update CI baseline
* Replace manual dependency check with manifest-based one
* Remove v0.8 version
* Update CI baseline
---------
Co-authored-by: chausner <chausner@users.noreply.github.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* [duktape] Update to 2.7.0 and don't require python2 to build.
Instead use a release tarball which includes all codegened stuff.
* [duktape] Enable in CI.
Don't enforce a hardcoded nesting limit as these limits are enforced by
GitLab itself and may change in the future. Furthermore I believe that
users can be trusted to successfully copy'n'paste the path portion of an
URL. Therefore we just require that the assumptions of our
implementation hold, i.e. that we can convert the repo path to a CMake
list by replacing `/` with `;` and that there is a repository name.