* [libwebp] update to v1.0.2, greatly simplify port, remove unnecessary custom find_package script in favour of original Config files for cmake
* [libwebp] enable building of all tools
* [libwebp] install cmake config file in expected path
* [libwebp] add compatibility layer inside CMake Config file
* [libwebp] fix libwebpmux library name
* [OpenEXR] Update to v2.3.0, enable tools, improve cmake module while still maintaining backwards compatibility (there's an official one distributed with the package but it is completely different, for now it is avoided)
* [OpenEXR] remove unused patches
* [OpenEXR] remove forced definition, could hide problems downstream
* [freeimage] add compatibility with latest OpenEXR
* [freeimage] bump control
* [OpenEXR] restore ilmbase as an empty package to permit clean update
* [OpenVDB] update to v6.0
* [OpenEXR] disable building on UWP platform
* [openexr] Fix tools suffixes
* [openexr] Fix Linux build paths
* Add X-Plane SDK support
* fix: disallow x86 builds
The x-plane SDK website claims that the SDK is only
compatible with x64. The PR that adds support for this
fails in x86, so I'm disallow x86 builds to align with
the x-plane documentation.
* fix: install sdk headers to the root include path
The x-plane SDK website's examples expect that the sdk
headers are at the root of the include path. I'm adjusting
this port to align with those samples, as we want examples
to "just work" as much as possible.
* style: whitespace
* Remove ununsed directory
* Update qt5-base to 5.12.1
* update qt5-declarative to 5.12.1
* update qt5-modularscripts for 5.12.1
* update qt5-3d to 5.12.1
* update qt5-activeqt to 5.12.1
* add qt5-connectivity
* update qt5-charts to 5.12.1
* update qt5-datavis3d to 5.12.1
* update qt5-gamepad to 5.12.1
* update qt5-graphicaleffects to 5.12.1
* update qt5-imageformats to 5.12.1
* add qt5-location
* update qt5-multimedia to 5.12.1
* update qt5-networkauth to 5.12.1
* add qt5-purchasing
* update qt5-quickcontrols to 5.12.1
* update qt5-quickcontrols2 to 5.12.1
* add qt5-remoteobjects
* update qt5-script to 5.12.1
* update qt5-scxml to 5.12.1
* add qt5-sensors
* update qt5-serialport to 5.12.1
* update qt5-speech to 5.12.1
* update qt5-svg to 5.12.1
* update qt5-tools to 5.12.1
* update qt5-virtualkeyboard to 5.12.1
* add qt5-webchannel
* update qt5-websockets to 5.12.1
* update qt5-winextras to 5.12.1
* update qt5-xmlpatterns to 5.12.1
* update framework port to 5.12.1 and include the new modules
* fix building qt5-base on linux
* [qt5] Remove non-alphanumerical ASCII chars from dependencies
* [mlpack] Add new port
Add new port for the http://www.mlpack.org/ library
* Tools optional and static build
* Info fix
* [mlpack] Use PATCHES parameter instead of apply_patches()
* Add X-Plane SDK support
The x-plane SDK website claims that the SDK is only
compatible with x64. The PR that adds support for this
fails in x86, so I'm disallow x86 builds to align with
the x-plane documentation.
The x-plane SDK website's examples expect that the sdk
headers are at the root of the include path. I'm adjusting
this port to align with those samples, as we want examples
to "just work" as much as possible.
* [vtk] Change the runtime dir from tools to bin to fix DLL location
* Also move the tools on unixoid OS; Fix tool names in targets files
* Remove duplicate vcpkg_copy_pdbs()
* [vtk] Change version to force rebuild in CI
* [lest] Add lest v1.34.0
* [lest] Add lest v1.34.1
To support vcpkg installations, examples now specify folder 'lest' in the include directives, like: #include "lest/lest.hpp".
* fix: update hash for lest
* [tiff]: disable libwebp support.
Since version 4.0.10, libtiff supports optional compression modes using
either libweb or zstd.
When libtiff is built, and libwebp and/or zstd are found anywhere on the
system, these modes will be enabled. However, the respective libraries
are not added as link targets, so this will result in linker errors for
any unsuspecting project using libtiff.
Since zstd support was already disabled by a previous commit, I have
also simply disabled libwebp support to fix this issue.
A more proper fix might be to add both libwebp and zstd as required
libtiff dependencies, and to patch libtiff's CMakeLists.txt, such that
these libraries are properly linked to. However, it is currently very
unlikely to encounter TIFF images in the wild compressed using either
of these methods, so the effect of disabling support may not be
noticeable at all.
* [tiff] Change CONTROL version
* [corrade] Update to v2019.01
Signed-off-by: Squareys <squareys@googlemail.com>
* [magnum] Update to v2019.01, remove shapes and glutapplication features
These features were deprecated in earlier versions and now removed.
Signed-off-by: Squareys <squareys@googlemail.com>
* [magnum-(extras,plugins,integration)] Update to v2019.01, add imgui feat.
Signed-off-by: Squareys <squareys@googlemail.com>
* [magnum] Improve dependencies to corrade
Signed-off-by: Squareys <squareys@googlemail.com>
* [magnum-plugins] Add faad2audioimporter
- faad2 is currently not in vcpkg, hence commented out
- The commented out empty line is required to have vcpkg parse the file
without issues
Signed-off-by: Squareys <squareys@googlemail.com>
* [ampl-mp] Add new port
This port aims for solver development, so it does not build any
existing solver modules.
The shared library build is disabled for now because it has some
problem on Windows.
closes: #4491
* [ampl-mp] Disable MATLAB MEX support
* fix library exports for iconv on macOS, add Threads dependency for cairo, add the iconv, intl and Threads dependencies to harfbuzz
* updated portfile from harfbuzz fix
* fix indenting and order
* fix portfile
* [gettext] Add unofficial-gettext targets
* [gettext] Fixup for Linux
This is so that you can derive a class from things like `rocksdb::AssociativeMergeOperator`. Perhaps a more "correct" patch would be to see if rtti is enabled for other builds, and enable it here, though it's not clear to me if that's feasible, so I'm suggesting this.
* add support for building hyperscan
* patch hyperscan to work with latest boost
* correct hyperscan source dir name
* speed the build by depending on only the parts of boost we actually need
* make python3 support release-only builds
* upgrade to hyperscan 5.1.0
* remove redundant disambiguate patch
* Add comments about how to build
* restore original x64-windows-static.cmake
* [hyperscan] Check linkage
* [python3] Allow DLLs without LIBs
* [hyperscan] Only static library
* [python3] Revert changes that cause regression in boost-python
* [python3] Revert changes that cause regression in boost-python
* Added cmake targets for nlohmann-json
* [nlohmann-json] Use vcpkg_from_github()
* [nlohmann-json] Enable find_package(nlohmann_json)
* Removed unneeded renaming
* [nlohmann-json] Revert use of vcpkg_from_github() due to archive size of >100MB
* [nlohmann-json] Fix missing natvis
Netcdf and HDF are important _formats_ in the scientific domains (lots of satellite data come in nc or hdf) so having them by default in GDAL seems the most natural.
* [systemc] Add new port (Microsoft#5250)
* [systemc] Fix debug targets
* [systemc] Use vcpkg_extract_source_archive_ex()
* [systemc] Disable vcpkg_test_cmake() for now due to issues
* [systemc] Fixup cmake targets
* Remove the libmysql dependency
The fact that it's not possible to build libmysql for x86 is a source of troubles for projects that have GDAL as a dependency. Though it's possible to build GDAL separately for x64 & x86 this is very confusing and breaks other builds. For example I'm often crossing this issue when trying to build a local GMT package. So the best is to just remove it as a dependency.
```
C:\programs\compa_libs\vcpkg>vcpkg install gmt:x86-windows --recurse
The following packages will be built and installed:
* gdal[core,mysql-libmysql]:x86-windows
gmt[core]:x86-windows
* libmysql[core]:x86-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/3: libmysql:x86-windows
Building package libmysql[core]:x86-windows...
CMake Error at C:/programs/compa_libs/vcpkg/ports/libmysql/portfile.cmake:10 (message):
Oracle has dropped support in libmysql for 32-bit Windows.
```
* Revert "Remove the libmysql dependency"
* Remove the libmysql dependency
The fact that it's not possible to build libmysql for x86 is a source of troubles for projects that have GDAL as a dependency. Though it's possible to build GDAL separately for x64 & x86 this is very confusing and breaks other builds. For example I'm often crossing this issue when trying to build a local GMT package. So the best is to just remove it as a dependency.
```
C:\programs\compa_libs\vcpkg>vcpkg install gmt:x86-windows --recurse
The following packages will be built and installed:
* gdal[core,mysql-libmysql]:x86-windows
gmt[core]:x86-windows
* libmysql[core]:x86-windows
Additional packages (*) will be modified to complete this operation.
Starting package 1/3: libmysql:x86-windows
Building package libmysql[core]:x86-windows...
CMake Error at C:/programs/compa_libs/vcpkg/ports/libmysql/portfile.cmake:10 (message):
Oracle has dropped support in libmysql for 32-bit Windows.
```
* Update boost to 1.69. Fixes#5023
- Remove boost-signal (rationale: deprecated and removed in 1.69)
- Remove boost-hana workaround by xiangfan-ms #4186#3579 (rationale: 1.69 incorporates required fixes in hana master branch; builds fine in VS2017 15.9)
* [boost-signals] Restore signals from boost 1.68 because it is required by wt
* [boost-vcpkg-helpers] Improve dependency detection
* [boost-iostreams] Revert to cmake build to enable dependencies
* [boost-iostreams] Fix use of zstd in static builds
* [libtorrent] Update to 1.2.0
* [wt] Update to 4.0.5
* [boost-safe-numerics] [boost-vcpkg-helpers] Added safe_numerics; slight mod to regex match
* [hpx] Backport boost 1.69 fixes
* [libtorrent] Clean up cmake file installation
* [boost-type-traits] Fix MSVC arm
* libass dynamic library
it relies on fribidi, harfbuzz, fontconfig, libiconv
* Remove references to iconv and fontconfig
Because this port is currently Windows-only (Fribidi doesn't build on
Linux with vcpkg because of an issue with Meson), we don't want to worry
about FontConfig; DirectWrite should be enough.
* Freetype is important!
* Remove unnecessary fontconfig -- for real
* Remove unnecessary comment
* [BZip2] Fix Unix Dynamic Builds
* [bzip2] Bump control version
* [libgta] Only build one flavor
* [vcpkg_configure_cmake] Resolve#2375 since we now use CMake >= 3.11
* [json-spirit] Add initial port
* Modify PR to using pn85, enable some features
json-spirit is a weird case because the main repo that package managers
tend to use appears to not be actively maintained. Nevertheless, vcpkg
tries to use the "official" source of a repository if at all possible.
In order to do this, I've made the following changes to the PR:
- I've changed the upstream REPO, REF, and SHA512.
- I've passed options to disable building the demos and tests
- I've made the project build only as a static library.
The reason for this is that vcpkg does not support dynamical linkin.
Another reason is that the library as it is in the repo does not have
all the definitions correctly annotated.smlee-hdactech has made a PR
against the major upstream repo to fix this, butwe are going to defer
to the main repo until that change is accepted.
* patch for building dll.
* [xsimd] Add new port
* Add a header include guard to xsimd's algorithm.hpp
algorithm.hpp is not guarded by a header include guard, which can cause
difficulty for users. xhihaoy asked that we be sure to include this
patch because it caused a lot of pain.
* [amqpcpp] Add new port
* Force static linkage for amqpcpp
The documentation for this library says that shared linkage on Windows
is unsupported. Furthermore, the build currently errors out on Windows
because shared DLLs are not placed correctly.
vcpkg only supports static linkage on Linux and macOS, so I'm
categorically making amqpcpp build with static linkage on all platforms.
This unifies the platforms and gives consistent behavior
* add CONTROL and portfile for spectralib 0.7.0
* Rename spectralib -> spectra
I'm making this change based on the naming in the other repositories
that the library is packaged in (DPorts, FreeBSD Ports) and the
terminology used on the website. Code examples use Spectra* for the
prefixes, so I think using "Spectra" is better than "spectralib".
* [json-spirit] Add initial port
* Modify PR to using pn85, enable some features
json-spirit is a weird case because the main repo that package managers
tend to use appears to not be actively maintained. Nevertheless, vcpkg
tries to use the "official" source of a repository if at all possible.
In order to do this, I've made the following changes to the PR:
- I've changed the upstream REPO, REF, and SHA512.
- I've passed options to disable building the demos and tests
- I've made the project build only as a static library.
The reason for this is that vcpkg does not support dynamical linkin.
Another reason is that the library as it is in the repo does not have
all the definitions correctly annotated.smlee-hdactech has made a PR
against the major upstream repo to fix this, butwe are going to defer
to the main repo until that change is accepted.
* [selene] Update to v0.3.
Add libtiff as a dependency.
Update release hash.
Remove the `vcpkg_check_linkage` call, since the relevant symbols for
shared libraries are now explicitly exported.
* [selene] Update to v0.3.1.
Also reinstate linkage check.
* [aws-c-common] Add new port
* [aws-checksums] Add new port
* [aws-c-event-stream] Add new port
* [aws-sdk-cpp] Update port to version 1.7.38
* [aws-sdk-cpp] Add dependencies on aws-c-event-stream, aws-checksums
This port currently only works on Windows because the dependencies of
the port (fribidi in particular) don't build on non-Windows platforms.
I made patch modifications to the source code because the Visual C++ C
compiler does not allow for non-constant-expression array indicesto be
used to declare a static array.
I've verified that this (1) builds on Windows and (2) works with a
sample test that's included in the libass github repo.
The GeoTIFF library ships with its own FindPROJ4.cmake module. This file
interferes with the cmake files that are installed by vcpkg for the PROJ4
package. As a result, the debug version of libgeotiff gets incorrectly
linked to the release version of PROJ4. By removing FindPROJ4.cmake from
the source directory, the vcpkg's .cmake files are used instead,
allowing CMake to find the debug version of PROJ4 when building the
debug version of libgeotiff.
* added patch to freetype for assigning a value to macros like HAVE_UNISTD_H as using newer macOS Frameworks fail to compile if they have no value
* [freetype] Modernize. Bump control version
