cmake: add export target config files

[nilason]

Alternative to #6869.

This is the first part of an update to add CMake support for g.extension, extracted here the CMake export target configuration files part, to simplify review .

In addition to the "pure" export, the following updates are added:

• reworked version handling (to account for version suffixes)
• changed some passing of relative paths to absolute in CMakeFiles

The targets exported are in the pattern GRASS::<grass-lib-name-in-lowercase>, e.g. GRASS::gis, GRASS::raster.

cc @m-kuhn

[nilason]

@m-kuhn Is there any possibility that you can test this PR soon, or will it be good for you to test later on from main when you find the time?

[m-kuhn]

It builds well here, thanks

There is one problem remaining, that (absolute) include paths of dependencies are propagated as include paths for grass and end up in the exported config.
These include paths are already defined in their own targets (GDAL::GDAL and PROJ::proj which are linked):
https://github.com/nilason/grass/blob/19517b0949e33c756f24ce054a14e87797aef8b1/lib/proj/CMakeLists.txt#L23

As far as I can see, this line can just be removed.

vcpkg build output (with the line removed):

Packages installed in this vcpkg installation declare the following licenses:
GPL-2.0-or-later
grass provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(GRASS CONFIG REQUIRED)
  # note: 50 additional targets are not displayed.
  target_link_libraries(main PRIVATE GRASS::dgl GRASS::gis GRASS::lrs GRASS::rli)

Is it correct, that we need all targets exported (I just did vector, raster and gis)?

[nilason]

It builds well here, thanks

Thanks for testing, really appreciate it!

There is one problem remaining, that (absolute) include paths of dependencies are propagated as include paths for grass and end up in the exported config. These include paths are already defined in their own targets (GDAL::GDAL and PROJ::proj which are linked): https://github.com/nilason/grass/blob/19517b0949e33c756f24ce054a14e87797aef8b1/lib/proj/CMakeLists.txt#L23

As far as I can see, this line can just be removed.

The problem is, unfortunately, that the GRASS lib's API exposes API from a couple of third party libraries. See #5263 for the rationale behind that line. So a third party software linking to the GRASS vector library also need, for example, GDAL include path, but not necessarily need to link to GDAL. I'm not sure how to solve that differently.

vcpkg build output (with the line removed):

Packages installed in this vcpkg installation declare the following licenses:
GPL-2.0-or-later
grass provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(GRASS CONFIG REQUIRED)
  # note: 50 additional targets are not displayed.
  target_link_libraries(main PRIVATE GRASS::dgl GRASS::gis GRASS::lrs GRASS::rli)

Is it correct, that we need all targets exported (I just did vector, raster and gis)?

How about find_package(GRASS REQUIRED COMPONENTS vector raster gis)?

[m-kuhn]

There is one problem remaining, that (absolute) include paths of dependencies are propagated as include paths for grass and end up in the exported config. These include paths are already defined in their own targets (GDAL::GDAL and PROJ::proj which are linked): https://github.com/nilason/grass/blob/19517b0949e33c756f24ce054a14e87797aef8b1/lib/proj/CMakeLists.txt#L23
As far as I can see, this line can just be removed.

The problem is, unfortunately, that the GRASS lib's API exposes API from a couple of third party libraries. See #5263 for the rationale behind that line. So a third party software linking to the GRASS vector library also need, for example, GDAL include path, but not necessarily need to link to GDAL. I'm not sure how to solve that differently.

I am do not completely understand the problem yet. These types are accessed through e.g. close_ogr.c or read_ogr.c but I didn't find in cmake, where this is built. If these files are compiled as part of vector, we also need to link to the gdal target. If they are not built, what's the reason for having these types used in the headers?

How about find_package(GRASS REQUIRED COMPONENTS vector raster gis)?

That's what I expect to use. Is there also a need for find_package(GRASS REQUIRED COMPONENTS dgl rls rli)? I am just wondering, I don't think it will hurt.

[nilason]

There is one problem remaining, that (absolute) include paths of dependencies are propagated as include paths for grass and end up in the exported config. These include paths are already defined in their own targets (GDAL::GDAL and PROJ::proj which are linked): https://github.com/nilason/grass/blob/19517b0949e33c756f24ce054a14e87797aef8b1/lib/proj/CMakeLists.txt#L23
As far as I can see, this line can just be removed.

The problem is, unfortunately, that the GRASS lib's API exposes API from a couple of third party libraries. See #5263 for the rationale behind that line. So a third party software linking to the GRASS vector library also need, for example, GDAL include path, but not necessarily need to link to GDAL. I'm not sure how to solve that differently.

I am do not completely understand the problem yet. These types are accessed through e.g. close_ogr.c or read_ogr.c but I didn't find in cmake, where this is built. If these files are compiled as part of vector, we also need to link to the gdal target. If they are not built, what's the reason for having these types used in the headers?

The GDAL (and PostgreSQL) types are part of struct Map_info, via struct Format_info:

grass/include/grass/vect/dig_structs.h

Line 1388 in bc06217

struct Format_info fInfo;

Map_info is used widely in the code so at this point, close before release, I can't think of a non-trivial fix that would address this. (I'd love to be proven to the contrary:)

I'll see if I can find out a workaround to target_include_directories. I'm curious, is the absolute path in the target a problem/blocker from your point of view?

How about find_package(GRASS REQUIRED COMPONENTS vector raster gis)?

That's what I expect to use. Is there also a need for find_package(GRASS REQUIRED COMPONENTS dgl rls rli)? I am just wondering, I don't think it will hurt.

The Addons typically use bitmap btree2 dbmibase gis gmath gproj imagery linkm raster segment vector. The rest of the libraries are not very likely to be used, but as the targets are generated automatically, why not keep them.