build: Add CMake build

[HuidaeCho]

This PR replaces #3021. Branched from https://github.com/nilason/grass/tree/cmake_build_work. Thanks @nilason!

Current status: I can compile the entire gisbase using CMake 3.29.1 and GCC 13.2.0. Running grass directly from build/gisbase works fine.

For my records, message from message(WIN32=${WIN32}, MSVC=${MSVC}, MSYS=${MSYS}, MINGW=${MINGW}) on Windows (all from cmd in ssh):

• Using MSYS cmake (cmd for MSVC): WIN32=,MSVC=,MSYS=1,MINGW= (WIN32 not set?)
  • CMake no longer defines WIN32 on MSYS xmrig/xmrig#950
  • https://developercommunity.visualstudio.com/t/win32-not-defined/722576
• Using MinGW-w64 cmake (bash for MinGW-w64 GCC): WIN32=1,MSVC=,MSYS=,MINGW=1

CMake variables:

• WIN32
• MSVC
• MSYS
• MINGW

TODOs:

• Windows
• macOS
• locale
• addon support
• ...

[nilason]

Now I expect the cmake runner to succeed...

[HuidaeCho]

Now I expect the cmake runner to succeed...

Yeah! Finally!

CMake / build-cmake (pull_request) Successful in 4m

[echoix]

Oh yeah, 2min52 build time. Is it with a cache hit or without cache?

[nilason]

Now only a "small" detail remains, I believe, before bringing this into review mode. Installation.

Traditionally, the Autotools installation looks like:

└── usr
    └── local
        ├── bin
        │   └── grass
        └── grass84
            ├── AUTHORS
            ├── CHANGES
            ├── CITING
            ├── COPYING
            ├── GPL.TXT
            ├── INSTALL.md
            ├── REQUIREMENTS.md
            ├── bin
            ├── contributors.csv
            ├── contributors_extra.csv
            ├── demolocation
            ├── docs
            ├── driver
            ├── etc
            ├── fonts
            ├── gui
            ├── include
            ├── lib
            ├── locale
            ├── scripts
            ├── share
            ├── translation_status.json
            ├── translators.csv
            └── utils

To make a smooth transition, I'd suggest we initially replicate that installation structure, but with possibility to easily change to a FHS compliant structure (see also discussion on grass-dev ML thread). Even better would be to be able to switch between the "traditional" and the new FHS with a configuration flag.

Installation file structure as of now with CMake, looks like:

└── usr
    └── local
        ├── bin
        │   ├── d.barscale
        │   ├── d.colorlist
        │   ├── d.colortable
        │   ├── d.erase
        │   ├── ...
        │   ├── v.what
        │   ├── v.what.rast
        │   └── v.what.rast3
        ├── docs
        │   └── html
        ├── driver
        │   └── db
        ├── etc
        │   ├── VERSIONNUMBER
        │   ├── clean_temp
        │   ├── ...
        │   ├── python
        │   ├── renamed_options
        │   ├── run
        │   └── sql
        ├── gui
        │   ├── icons
        │   ├── images
        │   ├── wxpython
        │   └── xml
        ├── lib
        │   ├── libgrass_cairodriver.8.4.0dev.dylib
        │   ├── libgrass_cairodriver.8.dylib -> libgrass_cairodriver.8.4.0dev.dylib
        │   ├── libgrass_cairodriver.dylib -> libgrass_cairodriver.8.dylib
        │   ├── ...
        │   ├── libgrass_rli.8.dylib -> libgrass_rli.8.4.0dev.dylib
        │   └── libgrass_rli.dylib -> libgrass_rli.8.dylib
        ├── scripts
        │   ├── d.background
        │   ├── d.correlate
        │   ├── d.frame
        │   ├── ...
        │   ├── v.what.strds
        │   ├── v.what.vect
        │   └── wxpyimgview
        └── share
            ├── appdata
            ├── applications
            └── icons

... which with some changes will probably conform to FHS. But we should also/primarily enable the "traditional" structure, which could be realised with clever use of variables.

[echoix]

Is there a way to already deprecate the "traditional" layout and make it clear when you choose to make cmake create the traditional layout instead of fhs?

When talking about fhs, I don't really stick to FHS, but anything that should be standard on that platform, like with the GNUInstallDirs module
https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html. Is there an equivalent for other platforms?

[nilason]

Started discussion #3661 on the new FHS complying structure.

[nilason]

Is there a way to already deprecate the "traditional" layout and make it clear when you choose to make cmake create the traditional layout instead of fhs?

We can only deprecate it when the new structure is tested well enough. Such changes are bound to lead to unexpected issues of every kind. I think the definite step to the new structure may be done only with a mayor version bump (e.g. GRASS 9).
Our adoption of CMake is important in particular for Windows, which is why -- in my opinion -- it is necessary to initially keep the "traditional" structure also for CMake builds. Otherwise it would certainly be easier to let the CMake adoption bring the new structure alone.

[nilason]

@HuidaeCho I hope you haven't worked on this any further, as I have done so. I have some made some extensive changes for enabling both current and FHS compliant install structure, which I will hopefully be able to commit soon.

[echoix]

@HuidaeCho I hope you haven't worked on this any further, as I have done so. I have some made some extensive changes for enabling both current and FHS compliant install structure, which I will hopefully be able to commit soon.

There's always the possibility to create a PR to his branch if you fear a force push/rebase

[nilason]

@HuidaeCho I hope you haven't worked on this any further, as I have done so. I have some made some extensive changes for enabling both current and FHS compliant install structure, which I will hopefully be able to commit soon.

There's always the possibility to create a PR to his branch if you fear a force push/rebase

I’m more worried about double work.

[HuidaeCho]

@nilason No worries. I haven't had a chance to work on it, but I'll resume very soon. So please make your commit when it's ready and let me know.

[HuidaeCho]

@nilason I was wondering about the status of your FHS work. Are you ready to commit it?

[nilason]

@nilason I was wondering about the status of your FHS work. Are you ready to commit it?

The framework is in place. It will certainly be necessary to fine-tune, at least for the FHS install, but it broadly works. At this moment, I'm working to produce an identical install package (file tree) as the present autoconfig build produces. For this is manual/doc generation and locale not implemented (independently of this FHS adaptation). I'm currently working on manual generation (indexing remains to be fixed).
I can push current stand if you will.

(Tip: testing installation is best made with make DESTDIR="path/to/install/dir" install from build directory. This avoids messing up the file system. Comparing the autoconfig installation with the cmake installation can be made with diff "dir1" "dir2").

[HuidaeCho]

@nilason I was wondering about the status of your FHS work. Are you ready to commit it?

The framework is in place. It will certainly be necessary to fine-tune, at least for the FHS install, but it broadly works. At this moment, I'm working to produce an identical install package (file tree) as the present autoconfig build produces. For this is manual/doc generation and locale not implemented (independently of this FHS adaptation). I'm currently working on manual generation (indexing remains to be fixed). I can push current stand if you will.

(Tip: testing installation is best made with make DESTDIR="path/to/install/dir" install from build directory. This avoids messing up the file system. Comparing the autoconfig installation with the cmake installation can be made with diff "dir1" "dir2").

Thanks for the update! Have we agreed on a specific FHS structure?

[nilason]

Thanks for the update! Have we agreed on a specific FHS structure?

What I have now, at the moment it, is what I proposed in #3661 (comment). But that is relatively easy to change if needed, only setting the variables.

[nilason]

Soo, I finally pushed a major commit! The base for FHS is in place. Build and install works for traditional file structure. I added test, which do not yet pass completely. There is still a lot to do, I cheated on CI with -DCMAKE_C_FLAGS="-I/usr/include -I/usr/include/gdal", which must be addressed properly. FHS will not really work properly without source changes (because of breaking up of GISBASE), I cheated with symlinks for build for the time being.
I will in the following weeks not be able to work on this, so please continue if you will.

[echoix]

Is COMMAND sh the cmake portable way of doing operations? In other words, does this tie compiling on windows to a msys2/cygwin environment?

[nilason]

WIP, Windows will be a challenge…

[echoix]

I know. Do you think having the CI ready for windows earlier would help or harm? Like seeing more failures than needed, but also tracking up to where the build can reach.

[echoix]

When the time will come I'll help out on the CI part, adding Mac and windows (if it is close) together. But probably not now

[nilason]

Looks like the failing tests are caused by (only) ctypesgen not finding libs.

[wenzeslaus]

...FHS will not really work properly without source changes (because of breaking up of GISBASE)...

Not the necessary changes, but the prep for that for grass.script and for the main executable is here: #3694. I'm not working on it right now, though.