* cppcms
* cudnn
* devicenameresolver
* epsilon
* fann
* cudnn license
* devicenameresolver version
* epsilon
* version
* Remove from ci baseline
* license
* version
* libbf
* version
* Why are those ports unsupported on static? I think because of failing post build lint
* version
* cppcms
* version
* epsilon
* version
* typo
* version
* test on static
* version
* cppcms not supported on static
* version
* cudnn
* device
* version
* try again...
* version
* version-date
* version
* [cppcms] Patch out tests & examples
* version
* Fix patch
* version
* remove debug include
* version
* [cppcms] copy pdbs
* version
* [saucer] add new port
[saucer] add lockpp dependency
beleg
* [lockpp] add new port
* [saucer] update ref
* [saucer] only support static
* fix: revert cibaseline
* refactor: also disable uwp
* [saucer,lockpp] remove superflous dependencies
* [lockpp] update version
* [saucer] update to 1.0.0
* [saucer] specifiy only static library
* [saucer] bump ref
* [saucer] remove unused dependency
Co-authored-by: Robert Schumacher <roschuma@microsoft.com>
* [saucer] use vcpkg webview2
Co-authored-by: Robert Schumacher <roschuma@microsoft.com>
* Adding libcaer port file
* Formatting libcaer config
* Adding version info
* Git tree update for libcaer
* Updating static builds and osx / linux platforms
* Version update
* Removing deprecated methods and fixing linux build
* libcaer version update
* Fix macos build
* Version update
* Macos test
* Version update
* Update patch file
* Version update
* Version update
* Fixing comments
* Formatting
* Versioning update
* Adding pkgconfig fixup
* Version update
Co-authored-by: Rokas Jurevicius <rokas.jurevicius@inivation.com>
* [getopt-win32] ARM64 support
* retrigger checks
* updated git-tree sha
* Specify ports that do not support ARM but were enabled by getopt-win32 adding support.
* Upated SHA's
* Update ports/getopt-win32/portfile.cmake
Formatting indentation fix.
Co-authored-by: Mengna Li <95600143+Adela0814@users.noreply.github.com>
* Formatting indentation fix.
* Update version database
* [getopt-win32] Use CMake
* Updating versions
Co-authored-by: Mengna Li <95600143+Adela0814@users.noreply.github.com>
Co-authored-by: Robert Schumacher <roschuma@microsoft.com>
* Consolidate autotools patches with pkg-config
Fixes mingw builds.
* No msbuild limitations for mingw
* Implement readline support
* Remove features which never built
* Bonjour support is osx only
* Move remaining support checks to manifest
* Remove libpq uwp fail from ci baseline
* Update versions
* libxslt update and switch to cmake
* give logs.
* Revert "give logs."
This reverts commit fddf7675c9.
* fine tuning
* version stuff
* format manifest
* ver db
* Trailing whitespace and terminal newline.
Co-authored-by: Billy Robert O'Neal <bion@microsoft.com>
* [llvm] update to v14.0.0
* [llvm] BOLT sub-project support
* [llvm] fix tools install paths
* [halide] update to v14.0.0
* update versions
* [vcpkg-get-python-packages] fix "LOGNAME should be specified" warning
* [mesa] update to v22.0.1
* update versions
* update versions
* update version
* [mesa] update to 22.0.2
* update version
* [mesa] update patches
* update version
* [llvm] update to v14.0.3
* update version
* [llvm] remove depricated feature
* [llvm] allow to build OpenMP on Windows and remove incomplete cross-compile support
* update version
* [llvm] use vcpkg_cmake_get_vars
* [llvm/openmp] install CMake file in share/openmp
* [llvm] add vcpkg-cmake-get-vars dependency and slip post build check if OpenMP is enabled
* update version
* [lua] Fix library type and usage
* version
* Use c code in executables
* version
* Apply suggestion
* version
* Add an extra CMakeLists.txt to avoid scope pollution of SET_SOURCE_FILES_PROPERTIES
* version
* Apply suggestions
* version
* Various nitpicks:
* Use "supports" on features rather than if tests plus message FATAL_ERROR
* Deduplicate ENABLE_LUA_CPP and COMPILE_AS_CPP
* Add quotes.
* Use file(INSTALL rather than configure_file(COPYONLY)
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* move vcpkg-cmake-get-vars to its own helper port
* manifest format
* version stuff
* doc and version stuff
* add missing include
* version bump
* remove coypright copying.
* version stuff
Co-authored-by: Alexander Neumann <you@example.com>
* [liburing] Update to version 2.1
* format vcpkg.json
* x-add-version
* apply suggestion
* version
Co-authored-by: Lily Wang <v-lilywang@microsoft.com>
* Update to 3.0
* Modernize portfile
* Install NOTICE as required by license
* Move CMake config to unofficial namespace
The target name changed, so old configs would break anyways,
without polyfill. The unofficial namespace reflects such risks.
* Add include path to CMake config
* Update versions
* [luasec] upgrade to 1.1.0
* [luasec] Replace deprecated functions
* Run vcpkg x-add-version --all
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* [luasocket] Bump to official v3.0.0 release
Upstream changed to https://github.com/lunarmodules/luasocket and an
actual 3.0.0 release was tagged so we no longer need to point to
unversioned commits.
* [luasocket] Specify license in manifest
* Run vcpkg x-add-version --all
* Fix building LuaJIT on Linux
* Update version metadata
* Fix remaining ci.baseline.txt entries:
luajit:arm64-windows: Left as "skip": The problem is that the batch files used to build here want to run a binary they built which fails, but there's no good way to say "I can run the results" in our platform expressions right now
luajit:arm64-uwp / luajit:arm-uwp: These are already stopped by the platform expression.
luajit:x64-osx: I don't know if this works yet but we should try.
* Block osx with a "supports".
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* [libvpx,lmdb,aubio,freetype-gl,intelrdfpmathlib,libbson,libtcod,metis,pqp,smpeg2] Build fixes 2022-04-28
These results are from the most recent CI run: https://dev.azure.com/vcpkg/public/_build/results?buildId=71465
PASSING, REMOVE FROM FAIL LIST: aubio:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
I also did some investigation as to why aubio:arm-uwp didn't pass. Turns out, it's because aubio depends on ffmpeg, which failed to build because it depends on libvpx, which we never fixed for UWP following the VS2022 update. See also https://developercommunity.visualstudio.com/t/MicrosoftVisualStudioComponentVCTool/10002207?space=62&scope=follow&sort=newest
PASSING, REMOVE FROM FAIL LIST: freetype-gl:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
I also checked freetype-gl:arm-uwp, but it's blocked by glew which is blocked by opengl which appears to not be a thing on arm.
PASSING, REMOVE FROM FAIL LIST: intelrdfpmathlib:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
The arm-uwp version of this emits errors that look like source issues; I blocked arm&windows with a supports expression:
D:\buildtrees\intelrdfpmathlib\src\athLib20U2-d2a8954428.clean\LIBRARY\src\bid_functions.h(3113): error C2719: 'x': formal parameter with requested alignment of 16 won't be aligned
PASSING, REMOVE FROM FAIL LIST: libbson:arm-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: libbson:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: libtcod:arm-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: libtcod:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: lmdb:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
arm-uwp failed with again what looks like a source issue:
mdb.c.obj : error LNK2001: unresolved external symbol __tls_used
mdb.c.obj : error LNK2001: unresolved external symbol _mdb_tls_cbp
PASSING, REMOVE FROM FAIL LIST: metis:arm-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: metis:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: pqp:arm-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: pqp:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: smpeg2:arm-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
PASSING, REMOVE FROM FAIL LIST: smpeg2:x64-uwp (C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt).
I also checked Linux and it says
Could NOT find ibverbs (missing: IBVERBS_INCLUDE_DIRS IBVERBS_LIBRARIES)
which may be vcpkg's fault so I left that ci.baseline.txt skip alone.
REGRESSION: jansson:arm-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add jansson:arm-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
REGRESSION: jansson:x64-uwp failed with POST_BUILD_CHECKS_FAILED. If expected, add jansson:x64-uwp=fail to C:\a\1\s\scripts\azure-pipelines/../ci.baseline.txt.
Already fixed by https://github.com/microsoft/vcpkg/pull/24466
* dos2unix the patch
* :dos2unix the other patches too
* [toolchain windows] set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR
In specific, I did this for the cpuinfo PR - I realized the reason
that cpuinfo doesn't support arm64 windows cross compilation is because
we don't set CMAKE_SYSTEM_PROCESSOR.
* correctly set CMAKE_CROSSCOMPILING
* start fixin libraries
* more changes:
- gainput: remove line
- glog: remove try_run when cross compiling
- windows.cmake: set CMAKE_SYSTEM_VERSION
* more patches
- mapnik: set BOOST_REGEX_HAS_ICU to avoid check_cxx_source_runs
- orc: set HAS_PRE_1970 and HAS_POST_2038 for same
- seal: change out check_cxx_source_runs for check_cxx_source_compiles
* more changes
* fix x86-windows
* fix qpid-proton, glog
* build corrade-rc
* fix x64-uwp ports
* forgot to _actually_ always build corrade-rc .,.
* Replay #22831
* Dedupe CMAKE_SYSTEM_NAME settings.
* Add quotes for corrade_rc_param
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
* Update version DB.
Co-authored-by: nicole mazzuca <mazzucan@outlook.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
