* Fixed android toolchain with newest NDK
ANDROID_NATIVE_API_LEVEL has been removed from NDK cmake toolchain so we now have to use ANDROID_PLATFORM
* Fix android toolchain: Maintain backward compatibility for older NDK
* compile for android including armv6.
* Update arm-android.cmake
* Update from comment in the PR
support ANDROID_NATIVE_API_LEVEL from env variable. (to be able to compile also 16 and not just 21 as default)
* Add ANDROID_ARM_NEON from env var
* Short version of update ANDROID_ARM_NEON.
* remove ANDROID_NATIVE_API_LEVEL now using vcpkg_CMAKE_SYSTEM_VERSION in triplet
Add cache to ANDROID_ARM_NEON
fix indents
* Update neon triplet
* Add arm-neon-android.cmake file.
This change tries to fix issue #13395.
Root cause:
In script mode, cmake won't populate CMAKE_SYSTEM_PROCESSOR parameter automatically. That parameter is
required by libpng to configure build parameters. To fix this issue, we need explicitly set CMAKE_SYSTEM_PROCESSOR
value.
Verify:
On arm64-linux host, run `./vcpkg install tesseract:arm64-linux`.
Co-authored-by: Nicole Mazzuca <mazzucan@outlook.com>
Co-authored-by: JackBoosY <yuzaiyang@beyondsoft.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* Fix for Android compilation
See https://github.com/microsoft/vcpkg/issues/5809
* Allow for custom android triplets. Fallback to Xamarin installed NDK.
* Increased Port-Version for boost-modular-build-helper
* More restrictive matching pattern for android toolchain
* [vcpkg ios] Fix detection of iOS toolchain (#6003)
Added mapping of CMAKE_SYSTEM_NAME == iOS to the bundled iOS toolchain
file.
This fixes the "Unable to determine toolchain to use for
triplet arm64-ios with CMAKE_SYSTEM_NAME iOS" error.
* [vcpkg ios] Set the CMake system processor for the simulator arches (#6003)
So it's consistent for all architectures.
* Add iOS community triplets and toolchain support
Added an iOS toolchain to enable building packages for iOS.
The toolchain is used when a triplet's VCPKG_CMAKE_SYSTEM_NAME is set
to iOS.
To configure which architecture should be built, as well as other
iOS specifics, the following triplet variables can be set:
- VCPKG_TARGET_ARCHITECTURE
- VCPKG_OSX_SYSROOT
- VCPKG_OSX_DEPLOYMENT_TARGET
- VCPKG_OSX_ARCHITECTURES
The following VCPKG_TARGET_ARCHITECTURE values are currently
supported:
- arm, arm64, x64, x86.
The following VCPKG_OSX_SYSROOT values are currently supported:
- iphoneos, iphonesimulator, or an absolute path to the device or
simulator Xcode SDK.
VCPKG_OSX_DEPLOYMENT_TARGET can be set to control the minimum iOS
delopyment target for the built libraries.
CMAKE_OSX_ARCHITECTURES is derived from VCPKG_TARGET_ARCHITECTURE,
so generally it should not be set. In case if someone needs to target
a more specific architecture (like armv7k or arm64e), it can
be set in the triplet via VCPKG_OSX_ARCHITECTURES.
Note that only certain combinations of the architecture and sysroot
will work: simulator SDKs only provide x86-based libraries, etc.
The toolchain also sets CMAKE_SYSTEM_PROCESSOR for certain
configurations, because certain packages (like libpng) depend on the
processor type.
Added 4 community iOS triplets that build static libraries:
- arm-ios, arm64-ios, x86-ios, x64-ios.
The non-arm triplets target the iOS simulator.
The triplets build static libraries because they are easiest to
integrate into an iOS project. Dynamic libraries or frameworks require
code signing on iOS, which complicates integration.
Added heuristics to try and automatically detect what iOS triplet to
use when building your own CMake project (so when a CMake project sets
CMAKE_TOOLCHAIN_FILE to buildsystems/vcpkg.cmake), if no explicit
triplet is provided (VCPKG_TARGET_TRIPLET is undefined).
The heuristic checks for the values of CMAKE_SYSTEM_NAME and
CMAKE_OSX_ARCHITECTURES. Note that for this to work,
CMAKE_OSX_ARCHITECTURES needs to be set before the first project()
call in your CMake project.
Added workaround so find_package finds vcpkg installed packages
when targeting iOS.
This is done by saving / restoring the value of CMAKE_FIND_ROOT_PATH
while also adding the vcpkg package root in the find_package override
macro.
The workaround can be removed once vcpkg upgrades to CMake 3.15.0
or higher where the issue is fixed.
Fixes: #6003
* Fix building libpng and pcre2 targetting iOS
Fixes: #6003
* Add support for building with MinGW
Tested with MSYS2 MinGW 8.3.0, gcc-mcf.lhmouse MinGW 9.2.1,
and StephanTLavavej/mingw-distro!
* Add MinGW toolchain
From your MinGW configured shell you could just use vcpkg to
configure packages.
An x64-mingw triplet would look like:
```
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_ENV_PASSTHROUGH PATH)
set(VCPKG_CMAKE_SYSTEM_NAME MinGW)
```
* Add MinGW community tripplets
x64 tested with https://github.com/StephanTLavavej/mingw-distro
x86, arm64, arm tested with https://github.com/mstorsjo/llvm-mingw
* [vcpkg_configure_cmake] Add NO_CHARSET_FLAG option
* [vcpkg_configure_cmake] Add documentation for new NO_CHARSET_FLAG option
* [vcpkg_configure_cmake, windows toolchain] Handle NO_CHARSET_FLAG in toolchain
* [build.cpp] Add Windows toolchain to package hash
* [duilib,msix,thrift,tidy-html5] Use NO_CHARSET_FLAG to fix regressions
* [vcpkg] Fix CMAKE_SYSTEM_PROCESSOR
Add CMAKE_SYSTEM_PROCESSOR setting under UWP, Linux, and Darwin.
If explicitly specified VCPKG_CMAKE_SYSTEM_PROCESSOR in triplet files, CMAKE_SYSTEM_PROCESSOR is set to specified architecture.
* [vcpkg-toolchains] Move logic out of vcpkg_configure_cmake and into the toolchains.
* [rocksdb] Update to v5.15.10
* [rocksdb] Cleanup
* [rocksdb] Fix cmake targets name.
* [toolchains] Set NDEBUG in release
* [rocksdb] Disable vcpkg_test_cmake due to misbehavior in x64
* [tiff] Use lzma on linux
