OSGeo
[WIP] CMake HOW-TOs and Known Issues
Building on Windows
- Install Visual Studio Community Edition. Select these two components:
- MSVC v143 - VS 2022 C++ x64/x86 build tools (Latest)
- Windows 11 SDK (10.0.26100.0)
- Install Git for Windows
- Install Miniconda
curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-Windows-x86_64.exe
mkdir C:\opt
Miniconda3-latest-Windows-x86_64.exe /S /D=C:\opt\miniconda
C:\opt\miniconda\condabin\conda.bat init
- Start Developer Command Prompt for VS 2022
- Setup Conda for GRASS build
conda config --add channels conda-forge
conda config --set channel_priority strict
conda create -n grass cmake pkg-config winflexbison proj libgdal pcre fftw openblas pdal wxpython pywin32
- Download the source code
cd \opt
git clone [email protected]:OSGeo/grass.git
cd grass
- Build GRASS
conda activate grass
mkdir build
cd build
cmake .. -DWITH_OPENGL=OFF > cmake.log 2>&1
msbuild grass.sln -p:Configuration=Release > msbuild.log 2>&1
- Run GRASS
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\.grassrc85
g.proj -p
Yes, g.gui doesn't work yet...
Alternatively, rename grass.py to grass85.py just once to avoid a problem with import grass:
ren output\bin\grass.py grass85.py
and
python output\bin\grass85.py output\lib\grass85\demolocation\PERMANENT
Building on Linux
- Install Miniconda
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
chmod a+x Miniconda3-latest-Linux-x86_64.sh
mkdir ~/opt
./Miniconda3-latest-Linux-x86_64.sh -b -u -p ~/opt/miniconda
~/opt/miniconda/bin/conda init
. ~/.bashrc
- Setup Conda for GRASS build
conda config --add channels conda-forge
conda config --set channel_priority strict
conda create -n grass git cmake pkg-config make gcc gxx flex bison proj gdal xorg-libx11 xorg-xproto libopengl libgl-devel cairo postgresql gettext fftw openblas pdal libglu wxpython
- Download the source code
cd ~/opt
git clone [email protected]:OSGeo/grass.git
cd grass
- Build GRASS
conda activate grass
# create a missing symlink to libOpenGL.so
ln -sf $CONDA_PREFIX/lib/libOpenGL.so.0 $CONDA_PREFIX/lib/libOpenGL.so
mkdir build
cd build
# LD_LIBRARY_PATH=$CONDA_PREFIX/lib, PKG_CONFIG_PATH=, and -DCMAKE_PREFIX_PATH=$CONDA_PREFIX to avoid system libraries
LD_LIBRARY_PATH=$CONDA_PREFIX/lib PKG_CONFIG_PATH= cmake .. -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DIconv_IS_BUILT_IN=FALSE &> cmake.log
make -j$(nproc) &> make.log
- Run GRASS
./output/bin/grass
Known Issues for Windows
- Doesn't build
-DWITH_OPENGL=ON(default) - Getting many of these CMake warnings
CMake Warning (dev) at gui/wxpython/docs/CMakeLists.txt:14 (add_custom_command):
The following keywords are not supported when using
add_custom_command(TARGET): DEPENDS.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
- SQLite driver not working
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"
AttributeError: module 'grass.lib.vector' has no attribute 'Vect_get_num_areas'
(see for example https://github.com/OSGeo/grass/actions/runs/13475973886/job/37657021926#step:15:3753) Maybe that's why all the long temporal tests end up failing and get skipped, thus taking 22 min total
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.
=> I was reproducing it non stop even when cleaning+deleting the build folder before supper, but now I can't recreate it. And I restarted my IDE so I can't copy the output. The only thing different now is that when creating one of the PRs, I ran git clean -d -f -x so it might have removed some files not cleaned with make libsclean clean distclean from previous autotools-based builds..
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) cmake cache file: CMakeCache.txt
[ 43%] Building C object misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/main.c.o
cd /home/vscode/grass/build/misc && /usr/bin/cc -DGRASS_VERSION_DATE=\"2025\" -DPACKAGE=\"grassmods\" -I/home/vscode/grass/build/output/lib/grass85/include -I/opt/local/include -I/home/vscode/grass/misc/m.nviz.image -I/home/vscode/grass/lib/gis -I/home/vscode/grass/lib/ogsf -I/home/vscode/grass/lib/nviz -I/home/vscode/grass/lib/vector/Vlib -I/home/vscode/grass/lib/db/dbmi_base -I/home/vscode/grass/lib/db/dbmi_client -I/home/vscode/grass/lib/db/./dbmi_base -I/home/vscode/grass/lib/db/dbmi_driver -DGRASS_CMAKE_BUILD=1 -std=gnu11 -MD -MT misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/main.c.o -MF CMakeFiles/m.nviz.image.dir/m.nviz.image/main.c.o.d -o CMakeFiles/m.nviz.image.dir/m.nviz.image/main.c.o -c /home/vscode/grass/misc/m.nviz.image/main.c
[ 43%] Building C object misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/surface.c.o
cd /home/vscode/grass/build/misc && /usr/bin/cc -DGRASS_VERSION_DATE=\"2025\" -DPACKAGE=\"grassmods\" -I/home/vscode/grass/build/output/lib/grass85/include -I/opt/local/include -I/home/vscode/grass/misc/m.nviz.image -I/home/vscode/grass/lib/gis -I/home/vscode/grass/lib/ogsf -I/home/vscode/grass/lib/nviz -I/home/vscode/grass/lib/vector/Vlib -I/home/vscode/grass/lib/db/dbmi_base -I/home/vscode/grass/lib/db/dbmi_client -I/home/vscode/grass/lib/db/./dbmi_base -I/home/vscode/grass/lib/db/dbmi_driver -DGRASS_CMAKE_BUILD=1 -std=gnu11 -MD -MT misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/surface.c.o -MF CMakeFiles/m.nviz.image.dir/m.nviz.image/surface.c.o.d -o CMakeFiles/m.nviz.image.dir/m.nviz.image/surface.c.o -c /home/vscode/grass/misc/m.nviz.image/surface.c
[ 43%] Building C object misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/vector.c.o
cd /home/vscode/grass/build/misc && /usr/bin/cc -DGRASS_VERSION_DATE=\"2025\" -DPACKAGE=\"grassmods\" -I/home/vscode/grass/build/output/lib/grass85/include -I/opt/local/include -I/home/vscode/grass/misc/m.nviz.image -I/home/vscode/grass/lib/gis -I/home/vscode/grass/lib/ogsf -I/home/vscode/grass/lib/nviz -I/home/vscode/grass/lib/vector/Vlib -I/home/vscode/grass/lib/db/dbmi_base -I/home/vscode/grass/lib/db/dbmi_client -I/home/vscode/grass/lib/db/./dbmi_base -I/home/vscode/grass/lib/db/dbmi_driver -DGRASS_CMAKE_BUILD=1 -std=gnu11 -MD -MT misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/vector.c.o -MF CMakeFiles/m.nviz.image.dir/m.nviz.image/vector.c.o.d -o CMakeFiles/m.nviz.image.dir/m.nviz.image/vector.c.o -c /home/vscode/grass/misc/m.nviz.image/vector.c
In file included from /home/vscode/grass/build/output/lib/grass85/include/grass/vect/digit.h:3,
from /home/vscode/grass/build/output/lib/grass85/include/grass/vector.h:4,
from /home/vscode/grass/misc/m.nviz.image/vector.c:18:
/home/vscode/grass/build/output/lib/grass85/include/grass/vect/dig_structs.h:27:10: fatal error: ogr_api.h: No such file or directory
27 | #include <ogr_api.h>
| ^~~~~~~~~~~
compilation terminated.
gmake[2]: *** [misc/CMakeFiles/m.nviz.image.dir/build.make:135: misc/CMakeFiles/m.nviz.image.dir/m.nviz.image/vector.c.o] Error 1
gmake[2]: Leaving directory '/home/vscode/grass/build'
gmake[1]: *** [CMakeFiles/Makefile2:12501: misc/CMakeFiles/m.nviz.image.dir/all] Error 2
gmake[1]: Leaving directory '/home/vscode/grass/build'
gmake: *** [Makefile:146: all] Error 2
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 missingdeps
We see what Ninja considers missing dependencies:
vscode ➜ ~/grass (cmake-gitignore) $ 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
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/chouse.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/chousv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cmattr.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cmcpy.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cminv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cmmul.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cmmult.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cmprt.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/csolv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/cvmul.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/eigen.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/eigval.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/evmax.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/hconj.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/heigval.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/heigvec.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/hevmax.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/hmgen.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/house.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/housev.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/minv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/mmul.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/ortho.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/psinv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/qrbdi.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/qrbdu1.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/qrbdv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/qrecvc.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/qreval.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/solv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/solvps.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/sv2u1v.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/sv2uv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/sv2val.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/svdu1v.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/svduv.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/svdval.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/trncm.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/unitary.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/utrncm.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Missing dep: lib/CMakeFiles/grass_ccmath.dir/external/ccmath/utrnhm.c.o uses /home/vscode/grass/lib/external/ccmath/ccmath.h (generated by phony)
Processed 4212 nodes.
Error: There are 41 missing dependency paths.
41 targets had depfile dependencies on 1 distinct generated inputs (from 1 rules) without a non-depfile dep path to the generator.
There might be build flakiness if any of the targets listed above are built alone, or not late enough, in a clean output directory.
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 missingdeps
I 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_MESSAGES
Does not happen when adding -DWITH_NLS=OFF
- Getting many of these CMake warnings
CMake Warning (dev) at gui/wxpython/docs/CMakeLists.txt:14 (add_custom_command): The following keywords are not supported when using add_custom_command(TARGET): DEPENDS. Policy CMP0175 is not set: add_custom_command() rejects invalid arguments. Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it.
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: (git clean -d -f -x in between each):
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 :
git clone [email protected]:OSGeo/grass.git doesn't work because the Developer Command Prompt starts in C:\Program Files\Microsoft Visual Studio\2022\Community and there is no write permission on this protected folder. you have to change to a writeable folder e.g. C:\opt to proceed.
but then, winGRASS builds. :-)
anything I should look at in the build logs?
getting many warnings in a windows test build, like, e.g.
CMake Warning (dev) at cmake/modules/build_gui_in_subdir.cmake:90 (add_custom_command):
COMMENT requires exactly one argument, but multiple values or COMMENT
keywords have been given.
Policy CMP0175 is not set: add_custom_command() rejects invalid arguments.
Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
Call Stack (most recent call first):
gui/wxpython/CMakeLists.txt:50 (build_gui_in_subdir)
This warning is for project developers. Use -Wno-dev to suppress it.
find attached warnings and errors mentioned in msbuild.log; build in a win 11 box
now tested the how-to locally on windows.
some minor comments to the how-to:
while at Start Developer Command Prompt for VS 2022 :
git clone [email protected]:OSGeo/grass.gitdoesn't work because the Developer Command Prompt starts in C:\Program Files\Microsoft Visual Studio\2022\Community and there is no write permission on this protected folder. you have to change to a writeable folder e.g. C:\opt to proceed.but then, winGRASS builds. :-)
anything I should look at in the build logs?
Thanks for testing! Good catch! I'll update the HOW-TO. Please test binaries. Do they work properly?
getting many warnings in a windows test build, like, e.g.
CMake Warning (dev) at cmake/modules/build_gui_in_subdir.cmake:90 (add_custom_command): COMMENT requires exactly one argument, but multiple values or COMMENT keywords have been given. Policy CMP0175 is not set: add_custom_command() rejects invalid arguments. Run "cmake --help-policy CMP0175" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): gui/wxpython/CMakeLists.txt:50 (build_gui_in_subdir) This warning is for project developers. Use -Wno-dev to suppress it.
Yes, that's known and documented above.
Please test binaries. Do they work properly?
how can I test the binaries?
For now, g.gui doesn't work, but you can still run binaries from cmd using this grass.bat:
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\.grassrc85
Run this grass.bat and you'll be in the demo location.
Another way is
ren output\bin\grass.py grass85.py
only 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 CMakePresets.json, directly supported by CMake 3.19+, instead of their custom solution, I directly edited the base windows preset with extra config needed. I was then able to not enter any arguments on the command line and only use the IDE.
https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html
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
As I note below, it was missing the apps folder, because gdal's CMake config files (.cmake) are there instead of with the other ones.
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 Cairo::Cairo instead of a plain normal CAIRO target though, which is not a bad thing.
I had to remove/rename the FindGDAL and use the method written in https://gdal.org/en/stable/development/cmake.html
find_package(GDAL CONFIG REQUIRED)
And also had to change to use the imported target GDAL::GDAL like explained in GDAL's doc. But today I wonder if all that was really needed for GDAL, as what I think made it work, was to add the $env{OSGEO4W_ROOT}\apps\gdal or $env{OSGEO4W_ROOT}\apps (I don't remember exactly) to the CMAKE_PREFIX_PATH, so maybe only that was enough. But anyways, that apps folder is also there that the gdal_share_dir is (inside the gdal subdirectory).
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 find_package(SQLite3 REQUIRED), and it creates the imported target SQLite::SQLite3. This means to change the SQLITE targets with the imported target. It's also different because the cmake cache variables are upper and lower case + 3 as opposed to only uppercase.
For flex + bison, I started from the solution for bison noted here https://discourse.cmake.org/t/how-i-get-bison-flex-on-windows/13505 and here https://stackoverflow.com/a/79394803
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 FLEX_ROOT to the same value as BISON_ROOT (they are downloaded at the same place).
I also saw a similar and improved version used for ports in vcpkg, based on https://learn.microsoft.com/en-us/vcpkg/maintainers/functions/vcpkg_find_acquire_program.
It is here: https://github.com/microsoft/vcpkg/blob/9a7a33fee37f3cbd9332fc2f83593335b1196057/scripts/cmake/vcpkg_find_acquire_program(BISON).cmake and https://github.com/microsoft/vcpkg/blob/9a7a33fee37f3cbd9332fc2f83593335b1196057/scripts/cmake/vcpkg_find_acquire_program(FLEX).cmake
Finally, I wasn't able to completely use only OSGeo4W deps. I had to use vcpkg for fftw, pcre, and for the fun pkgconf to allow the configure step to use package config (it seemed to work without). These were built once when configuring (or after deleting the build folder) and it takes less than a minute for all of it.
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
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.
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
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 https://github.com/OSGeo/grass/issues/5192#issuecomment-2676482794, and that's probably why the tests take 1/3 of the expected time.
I've been seeing a these errors in the logs since a while, it seems that the gui/wxpython/xml/module_items.xml is not available when running the tests in CI. Is that file correctly generated?
https://github.com/OSGeo/grass/actions/runs/13819798042/job/38662104433#step:15:832
======================================================================
FAIL: test_terminal_output (__main__.TestSearchModule)
----------------------------------------------------------------------
Traceback (most recent call last):
File "etc/python/grass/gunittest/case.py", line 1390, in assertModule
module.run()
File "etc/python/grass/pygrass/modules/interface/module.py", line 833, in run
self.wait()
File "etc/python/grass/pygrass/modules/interface/module.py", line 854, in wait
raise CalledModuleError(
grass.exceptions.CalledModuleError: Module run `g.search.modules keyword=water` ended with an error.
The subprocess ended with a non-zero return code: 1. See the following errors:
b'Traceback (most recent call last):\n File "scripts/g.search.modules", line 330, in <module>\n sys.exit(main())\n File "scripts/g.search.modules", line 102, in main\n modules = _search_module(keywords, AND, NOT, manpages, exact_keywords)\n File "scripts/g.search.modules", line 203, in _search_module\n menudata_file = open(filename)\nFileNotFoundError: [Errno 2] No such file or directory: \'gui/wxpython/xml/module_items.xml\'\n'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "scripts/g.search.modules/testsuite/test_g_search_modules.py", line 41, in test_terminal_output
self.assertModule(module)
File "etc/python/grass/gunittest/case.py", line 1410, in assertModule
self.fail(self._formatMessage(msg, stdmsg))
AssertionError: Running <g.search.modules> module ended with non-zero return code (1)
Called (Python): g.search_modules(keyword=['water'])
Called (Bash): g.search.modules keyword=water
See the following errors:
Traceback (most recent call last):
File "scripts/g.search.modules", line 330, in <module>
sys.exit(main())
File "scripts/g.search.modules", line 102, in main
modules = _search_module(keywords, AND, NOT, manpages, exact_keywords)
File "scripts/g.search.modules", line 203, in _search_module
menudata_file = open(filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gui/wxpython/xml/module_items.xml'
----------------------------------------------------------------------
Ran 6 tests in 0.841s
FAILED (failures=6)
========================================================================
FAILED ./scripts/g.search.modules/testsuite/test_g_search_modules.py (6 tests failed)
I've been seeing a these errors in the logs since a while, it seems that the
gui/wxpython/xml/module_items.xmlis not available when running the tests in CI. Is that file correctly generated?https://github.com/OSGeo/grass/actions/runs/13819798042/job/38662104433#step:15:832
It is not available on CMake build with -DWITH_GUI=OFF, which is the case on CI. At least currently. The menu handling depends unfortunately ultimately on wxPython, which is not available in the runner.
This latter circumstance is also shown by the autotools build:
GISRC=/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/demolocation/.grassrc85 GISBASE=/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu PATH="/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/bin:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/bin:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/scripts:$PATH" PYTHONPATH="/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/etc/python:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/gui/wxpython:$PYTHONPATH" LD_LIBRARY_PATH="/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/bin:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/bin:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/scripts:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/lib:/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/lib:/home/runner/install/lib" LC_ALL=C LANG=C LANGUAGE=C python3 core/menutree.py "manager" >> menustrings.py
Traceback (most recent call last):
File "/home/runner/work/grass/grass/gui/wxpython/core/menutree.py", line 41, in <module>
import wx
ModuleNotFoundError: No module named 'wx'
make[4]: *** [Makefile:53: menustrings.py] Error 1
make[4]: Leaving directory '/home/runner/work/grass/grass/gui/wxpython'
make[3]: [Makefile:35: default] Error 2 (ignored)
make parsubdirs
See https://github.com/OSGeo/grass/pull/3621#issuecomment-2671608636 and https://github.com/OSGeo/grass/pull/3621#issuecomment-2672364777
I've been seeing a these errors in the logs since a while, it seems that the
gui/wxpython/xml/module_items.xmlis not available when running the tests in CI. Is that file correctly generated? https://github.com/OSGeo/grass/actions/runs/13819798042/job/38662104433#step:15:832It is not available on CMake build with
-DWITH_GUI=OFF, which is the case on CI. At least currently. The menu handling depends unfortunately ultimately on wxPython, which is not available in the runner.
I think these g.search.modules tests need to be disabled when GUI is not build. Also, there are maybe other g.search.modules tests (or there is at least that functionality) which searchers through documentation, so that needs to be disabled when documentation is not build.
As for g.search.modules, it may need some fixes to behave nicely without GUI and doc. Perhaps, just better error messages. I don't think it need to work fully without them or that GUI and doc and then always needed.
As for module_items.xml, I mentioned a refactoring of GUI and the file generator code as a possible fix. Another fix, possibly bases for an ultimate fix here, is to move some of these strings from toolbox XML(s) to the tools themselves. The XML files now contain strings which are not in GUI code and not in tools. They are the short strings which appear in menu and the Tools tab, for example "Vector to raster" for v.to.rast. They are much shorter than the current labels (or descriptions) relying on context of the toolbox or just good guessing while not assuming users see or decode tool's name. Additionally, they should have generally a different tone, for example "Grow by one cell" versus "Generates a raster map layer with..." for r.grow. These could be part of the parser metadata for the tools significantly reducing the number of strings which need to be handled in special way while making these strings available to documentation and help text.
I've been seeing a these errors in the logs since a while, it seems that the
gui/wxpython/xml/module_items.xmlis not available when running the tests in CI. Is that file correctly generated? https://github.com/OSGeo/grass/actions/runs/13819798042/job/38662104433#step:15:832It is not available on CMake build with
-DWITH_GUI=OFF, which is the case on CI. At least currently. The menu handling depends unfortunately ultimately on wxPython, which is not available in the runner.I think these g.search.modules tests need to be disabled when GUI is not build. Also, there are maybe other g.search.modules tests (or there is at least that functionality) which searchers through documentation, so that needs to be disabled when documentation is not build.
As for g.search.modules, it may need some fixes to behave nicely without GUI and doc. Perhaps, just better error messages. I don't think it need to work fully without them or that GUI and doc and then always needed.
As for
module_items.xml, I mentioned a refactoring of GUI and the file generator code as a possible fix. Another fix, possibly bases for an ultimate fix here, is to move some of these strings from toolbox XML(s) to the tools themselves. The XML files now contain strings which are not in GUI code and not in tools. They are the short strings which appear in menu and the Tools tab, for example "Vector to raster" for v.to.rast. They are much shorter than the current labels (or descriptions) relying on context of the toolbox or just good guessing while not assuming users see or decode tool's name. Additionally, they should have generally a different tone, for example "Grow by one cell" versus "Generates a raster map layer with..." for r.grow. These could be part of the parser metadata for the tools significantly reducing the number of strings which need to be handled in special way while making these strings available to documentation and help text.
Thanks for this clarification!
I have started a wiki page which we can more freely update as work is progressing. Now, on my machine I'm able to build and run GRASS just as with autotools build. So, for anyone who is curious, please give it a try.
There are two areas where considerable work remain: generation of documentation (which is partially stalled by current transition to Markdown) and handling of Addons (g.extension).
I added a call to grass --config in the print_versions.sh script to help debug one of my PRs. I was surprised to see that the cmake workflow failed, because it is not supported with the cmake build.
ERROR: Please install the GRASS GIS development package
Exiting...
https://github.com/echoix/grass/actions/runs/14563718028/job/40850152423?pr=407#step:13:40
Is there anyone that knows if it works or has the commands needed to do the equivalent of the macos.yml CI job with CMake? I want to test an hypothesis concerning some missing code coverage data, and before going down another rabbit hole, I'm asking if anyone has progressed on something before.
@HuidaeCho
For non-OpenGL builds on Windows, I added %GISBASE%\scripts to the PATH, and the GUI was displayed successfully.
Could you help test this by running the following commands?
set GRASS_BUILD=C:\opt\grass\build
set GISBASE=%GRASS_BUILD%\output\lib\grass85
set PATH=%GISBASE%\bin;%GISBASE%\lib;%GISBASE%\scripts;%PATH%
set GISRC=%GISBASE%\demolocation\.grassrc85
