[WIP] CMake HOW-TOs and Known Issues #5192
Comments
Known Issues for Windows
v.db.select country_boundaries
dbmi: db_open_database() not implemented
dbmi: db_open_database() not implemented
WARNING: Unable to open database
<C:\Users\hcho\Documents\grassdata/world_latlong_wgs84/PERMANENT/sqlite/sqlite.db>
by driver <sqlite>
ERROR: Unable to open database
<C:\Users\hcho\Documents\grassdata/world_latlong_wgs84/PERMANENT/sqlite/sqlite.db>
by driver <sqlite> |
|
On CI, I think there's a problem of building the ctypes grass.lib.vector: Multiple tests fail when trying to use "Vect_get_num_areas" (see for example https://github.com/OSGeo/grass/actions/runs/13475973886/job/37657021926#step:15:3753) |
|
Locally, on a ubuntu 22.04 container (my dev environment for vscode, works well), I end up not being able to build, as there's a linking error for 4 bz_.... symbols. When building with Unix makefiles, not using multiple jobs, I get an error for "#include <ogr_api.h>". How can I make sure I have that enabled too when building with autotools version? (As that dev environment worked for a while even when cleaning and all, and I never saw that yet) With -j$(nproc), it happens at the very end. Edit: is that because I absolutely need the extra -D arguments like the CI to specify includes? The find_packages don't work enough? -> Seems like it |
|
With the following commands on cmake 3.31.4: cmake -B build -S . --fresh ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install -DWITH_NLS=OFF -DWITH_GUI=OFF -DWITH_DOCS=OFF
cmake --build build --verbose -- -t missingdepsWe see what Ninja considers missing dependencies: |
|
With CMake 3.31.4 and the following command (deleting the build directory beforehand): cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja --fresh
cmake --build build --verbose -- -t missingdepsI get: $ cmake --build build --verbose -- -t missingdeps
Change Dir: '/home/vscode/grass/build'
Run Build Command(s): /usr/local/python/current/bin/ninja -v -t missingdeps
ninja: error: build.ninja:53457: multiple rules generate output/lib/grass85/locale/ar/LC_MESSAGESDoes not happen when adding |
I see them on non-Windows, I suppose it is related to the arguments passed. For example: Shows multiple warnings: cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja -DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" -DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" -DCMAKE_INSTALL_PREFIX=$HOME/install Doesn't show these warnings: ( cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install \
-DWITH_GUI=OFF
cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install \
-DWITH_NLS=OFF -DWITH_GUI=OFF
cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install \
-DWITH_NLS=OFF -DWITH_DOCS=OFF
cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install \
-DWITH_GUI=OFF -DWITH_DOCS=OFF
cmake -B build -S . ${CMAKE_OPTIONS} -G Ninja \
-DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_CXX_FLAGS="-I/usr/include -I/usr/include/gdal" \
-DCMAKE_INSTALL_PREFIX=$HOME/install \
-DWITH_NLS=OFF -DWITH_GUI=OFF -DWITH_DOCS=OFF So, I must not have the three arguments for it to show (tried multiple times with same results) |
|
now tested the how-to locally on windows. some minor comments to the how-to: while at Start Developer Command Prompt for VS 2022 :
but then, winGRASS builds. :-) anything I should look at in the build logs? |
|
getting many warnings in a windows test build, like, e.g. |
|
find attached warnings and errors mentioned in msbuild.log; build in a win 11 box |
Thanks for testing! Good catch! I'll update the HOW-TO. Please test binaries. Do they work properly? |
Yes, that's known and documented above. |
how can I test the binaries? |
For now, set GRASS_BUILD=C:\opt\grass\build
set GISBASE=%GRASS_BUILD%\output\lib\grass85
set PATH=%GISBASE%\bin;%GISBASE%\lib;%PATH%
set GISRC=%GISBASE%\demolocation\.grassrc85Run this Another way is ren output\bin\grass.py grass85.pyonly once and python output\bin\grass85.py output\lib\grass85\demolocation\PERMANENT |
|
Yesterday I tried building with CMake on my install of Visual Studio 2022, my first time directly with Windows. I didn't want to use Conda, I wanted to see if it was possible to use the dependencies and dev dependencies from OSGeo4W, to see how close it was to have OSGeo4W change the packaging method. TLDR: not all of our dependencies are available or have dev-dependencies downloadable from OSGeo4W. First of all, I have a PR (still to create) with some .gitignore changes for the default build directories used by Visual Studio with CMake projects. I didn't manage to successfully complete a whole build yet, but got close to having a complete build. Obviously I was able to end up with a successful configuration step, but it took a while. Since Visual Studio now suggests to use Most of the config to use OSGeo4W deps was to port the equivalent of the what is done in the "cmakeenv" function, in regards to the paths added: https://github.com/jef-n/OSGeo4W/blob/e5c6a01be8abfa6265e85de7cfbe04eb1cfb23b9/scripts/build-helpers#L311-L350 I struggled quite a bit with Cairo, and the FindCairo.cmake in our repo. It always failed whilst I had all the files and paths there, and even added more variables doing the job of the FindCairo, but it still unset them in order to fail. I replaced that file with a more recent version on upstream WebKit, rewritten in 2020 https://github.com/WebKit/WebKit/blob/bc82205e7ef89756a44ccf963003c2cb439efe06/Source/cmake/FindCairo.cmake. With this, I had more luck and was able to continue. I had to change places to use the imported target I had to remove/rename the FindGDAL and use the method written in https://gdal.org/en/stable/development/cmake.html And also had to change to use the imported target I also had to remove/rename the FindSqlite.cmake, to use https://cmake.org/cmake/help/latest/module/FindSQLite3.html. So that means to use plain For flex + bison, I started from the solution for bison noted here if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
include(FetchContent)
FetchContent_Declare(download_bison
URL "https://github.com/lexxmark/winflexbison/releases/download/v2.5.25/win_flex_bison-2.5.25.zip"
URL_MD5 "720226b1befe7033fb3ecc98f5ffd425"
DOWNLOAD_EXTRACT_TIMESTAMP FALSE)
FetchContent_MakeAvailable(download_bison)
set(BISON_ROOT "${download_bison_SOURCE_DIR}")
message(STATUS "BISON_ROOT=${BISON_ROOT}")
endif()
find_package(BISON REQUIRED)but had to add Finally, I wasn't able to completely use only OSGeo4W deps. I had to use vcpkg for When building, I tried "Ninja" and "Visual Studio 2022" generators. Both I had some errors of "file or directory not found" of some steps using a bat file for multiple commands. I also saw some weird linking errors with ninja where it was trying to link x86 system libs with a x64 build, and didn't work, but didn't find the cause. With Visual Studio generator, it seemed to have less errors (build more), but was slower |
Thanks for the effort! Maybe we should drop a message in the osgeo4w mailing list to keep them updated. |
|
I'm getting many test failing on PR #2392 in the CMake workflow, but I don't see any relation to the PR (PR is raster mask, failing tests are vector-related). Please, let me know if you have any suggestions. https://github.com/OSGeo/grass/actions/runs/13507678405/job/37740965302?pr=2392 |
They were failing since the initial CMake PR was merged. I noted it in #5192 (comment), and that's probably why the tests take 1/3 of the expected time. |
Building on Windows
Yes,
g.guidoesn't work yet...Alternatively, rename
grass.pytograss85.pyjust once to avoid a problem withimport grass:ren output\bin\grass.py grass85.pyand
Building on Linux
conda config --add channels conda-forge conda config --set channel_priority strict # TODO: identify more system-independent Conda libraries conda create -n grass proj libgdal fftw blas libpdal wxpythonThe text was updated successfully, but these errors were encountered: