- The freexl port builds in vcpkg CI, and there are no open issues for
Windows.
- Either there are log files for the actual error, reported on the
console, or it fails early for example because of mixing different
msys2/cygwin runtimes.
- freexl is an optional feature of port gdal. If nothing as
I didn't pay much attention to the CMake code. Now:
You don't need to deal with string(CONCAT ...). Normally you just need to
- treat VCPKG__FLAGS as CMake string (because this follows
CMAKE__FLAGS),
- treat as VCPKG_CMAKE_CONFIGURE_OPTIONS as CMake list, *quoting whole
list items* if needed.
IMO you ask for trouble when you manually inject -DFRMT_mrsid=ON into
CFLAGS and CXXFLAGS. This is CMake input ("ON"!). Let the configuration
do that for you. Did configuration successfully detect the dependency?
Check the config logs.
Kai
Am 22.02.25 um 05:15 schrieb Michael Katz via gdal-d
In vcpkg, I see downstream build errors for pdal, osgearth, gz-common5.
This seems to be related the GDAL_DEBUG changes,
https://github.com/OSGeo/gdal/pull/11314, in the context of forward
declarations in non-gdal code. It is probably visible only in debug
builds. (Vcpkg builds debug and releas
In our builds, we statically link the Proj library into GDAL. This
approach is necessary because our product integrates with other
environments that often include their own GDAL builds. In the past,
dynamically linking the Proj library caused significant issues: these
other environments would s
r, we only add -lstdc++ when building a test program
fails without this explicit addition. Cf
https://github.com/OSGeo/gdal/blob/master/cmake/helpers/GdalCompilationFlags.cmake#L165
to L183
Le 06/07/2024 à 12:02, Kai Pastor, DG0YT via gdal-dev a écrit :
Why does it have to force anything at
Why does it have to force anything at all? CMake normally knows how to
setup CMAKE_CXX_IMPLICIT_LINK_LIBRARIES.
(Right now fixing hard-coded libstdc++ assumptions in ffmpeg and
dependencies in vcpkg, breaking Android.)
Kai
Am 06.07.24 um 09:59 schrieb Even Rouault via gdal-dev:
Hi,
when us
Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:
Hi,
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
I did a test build in vcpkg, and I see downstream problems with static
linkage. It now raises:
CMake Error at /mnt/vss/_work/1/s/scripts/buildsystems/vcpkg.cma
When you install gdal[tools], the apps are installed to
`/tools/gdal`.
(The vcpkg focus is on providing libs build from source.)
To explore port features, you can look at the port's vcpkg.json (aka
manifest), or start from
https://vcpkg.link/ports/gdal
Regards,
Kai
Am 20.02.24 um 12:22 schr
Am 15.02.24 um 00:42 schrieb Carl Godkin:
Hi Kai,
> To pass lists into cmake, you usually need ';' as item separator.
Thanks for the suggestion. I am sure I am missing something but
inserting a semi-colon on the Linux command line appears to require it
be escaped.
When I pass this:
-DW
Am 13.02.24 um 08:18 schrieb Michael Otto via gdal-dev:
I currently use an Ubuntu VM and use an Alpine-Linux Docker container
for compiling. First a static Geos library is created via cmake, then
a static Proj library (without Curl, because this currently leads to
errors) and then Gdal as a sta
To pass lists into cmake, you usually need ';' as item separator.
(Exception: CMAKE__FLAGS which is a command line fragment with
space-separated items.)
In vcpkg, webp is configured via a CMAKE_PROJECT_INCLUDE file:
if(GDAL_USE_WEBP)
find_package(WebP CONFIG REQUIRED)
add_library(WEBP:
Am 29.09.23 um 16:20 schrieb Abel Pau via gdal-dev:
I add next two lines below (ODBC is not in vcpkg?)
list(APPENDCMAKE_PREFIX_PATH "C:/dev/vcpkg/vcpkg/installed")
set(ODBCCPP_INCLUDE_DIR "D:/GitHub-repository/odbc-cpp-wrapper/src")
Note that vcpkg's CMake integration requires using vcpkg's CM
13 matches
Mail list logo