* 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
There are quite a few changes to the CMake build system packaged up into
one set here:
* Added `toolsrc/cmake/utilities.cmake`, which contains the following:
* `vcpkg_detect_compiler` -- get the name of the C++ compiler, as one
of {gcc, clang, msvc}
* `vcpkg_detect_standard_library` -- get the name of the standard
library we're linking to, as one of {libstdc++, libc++, msvc-stl}
* `vcpkg_detect_std_filesystem` -- figure out how to link and call
into C++17's filesystem; whether one needs to link to `stdc++fs` or
`c++fs`, and whether to use `<filesystem>` or
`<experimental/filesystem>`.
* Added a `VCPKG_WARNINGS_AS_ERRORS`, split off from
`VCPKG_DEVELOPMENT_WARNINGS`, which allows one to use the development
warnings without passing -Werror
* Rename `DEFINE_DISABLE_METRICS` to `VCPKG_DISABLE_METRICS` -- the
former will now print a deprecation message and set the latter.
* Now, print a deprecation message on `WERROR`; it doesn't do anything
since the behavior it requested is now the default.
* Pass `-std=c++17` if the compiler allows it, instead of `-std=c++1z`
* Do some code movement
* Pass `USE_STD_FILESYSTEM` if possible, instead of only on minGW
* Renamed to `VCPKG_USE_STD_FILESYSTEM`
Additionally, we now pass `/W4` in Debug mode on x86 in the Visual
Studio build system; this brings it in line with the CMake build system,
and the x64 Visual Studio build system.
And finally, we make some minor code changes to support compiling in
VCPKG_DEVELOPMENT_WARNINGS mode.
* [boringssl] Add new port
* removed usage of deprecated vcpkg functions
* let the ci treat boringssl like libressl
* applied requested changes
* [boringssl] Update to commit 590265773@2020-04-07 (#8455)
* [boringssl] Restore scripts/ci.baseline.txt
* copy the CMakeLists.txt file and start build with it
* change version to 2020.2
For now the repo doesn't have any tags.
Therefore its version followed the latest commit,
which is made in 2020 Feb.
* [qt5-imageformats] freeglut is not a dependency on osx
* [qt5-base] fontconfig can require iconv on linux and osx
* include the jasper fix to get CI coverage?
* trying to get ci coverage for qt on osx
* Revert "trying to get ci coverage for qt on osx"
This reverts commit 8b9b188839.
* apply the correct ci hack
* fix wrapper to include macosx debug suffix
* update baseline
* first try to fix the Qt5 cmake configs at the root.
* fix missing backslash
* fix plugin patch
* fix qt config patch
* remove 90% of fixcmake.py
* update baseline
* experimental removal of fixcmake.py and dll copying into tools/qt5/bin
* fix experimental dll copying.
* fix static windows builds
* fix static builds
* fix plugin copy
* add quotes around configuration to make it work
* remove dll debug messages
* note about the cmake fix
* revert fontconfig changes on linux. Make qt.conf relative and not absolute
* make qt.conf relative
* trying to fix ogre osx ci regression
* fix silly path error
* Revert "trying to fix ogre osx ci regression"
This reverts commit 708d8250d6.
* add ogre:x64-osx=fail to CI baseline
* retry on osx
* fix configure error. since in qt5-base everything is in the package directory and not in the installed
* revert change to ci.baseline
* update ci baseline
* bump control
* update baseline
* ws change to osg-qt
* reset ci baseline to upstream/master
* update baseline
* fix osg-qt?
* skip ms-angle on osx and linux since the normal angle port should be used!
* update ci baseline
* try adding fontconfig manually
* update ci baseline to remove osg-qt for the time being
* remove manual library.
* New policy: SKIP_DLL_ARCHITECTURE_CHECK.
The check only works if MS link.exe is used
otherwise the second linker member is missing
(according to the observed errors)
* rename to VCPKG_POLICY_SKIP_ARCHITECTURE_CHECK
since the dll check was ok but the lib check was failing.
* fix indentation
* move the if to a better position.
* [vcpkg] Correct UInt128 code 😇
`UInt128::operator<<(x, y)` should clear the bottom 64 bits of `x` if
`y >= 64`; however, we don't do this, and so we duplicate `x`'s bottom
bits into `x.top` instead of moving them. Similarly, we have the
opposite problem for `UInt128::operator>>`. This commit fixes these
latent bugs, which we weren't hitting because the thing we use them for
never actually shifts more than 64 bits.
