I've done some checking: FindGDal indeed sets the directory with the full path as you wrote, so the #includes in SGDemTile.hxx are correct.
Using include_directories() is no longer good CMake practice. The GDAL dependenyc is supposed to be handled by this logic in SimGear.cmake.in:
set(ENABLE_GDAL @ENABLE_GDAL@)
if (ENABLE_GDAL)
find_dependency(GDAL)
endif()
... which should find GDAL when Simgear is imported into FlightGear, if GDAL is enabeld of course.
Can you post the build errors you are seeing in FlightGear? You can also edit the installed SimGear.cmake (probabyl lives at /use/local/lib/cmake/SimGear/SimgearConfig.cmake) to check it looks correct, eg the @ substituion worked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I remove the include_directories of GDAL_INCLUDE_DIRS from the generated lib/cmake/SimGear/SimGearConfig.cmake, <gdal.h> can't be found when compiling flightgear/src/Airports/AirportBuilder.cxx:41.</gdal.h>
My manually modified lib/cmake/SimGear/SimGearConfig.cmake:
I don't think adding include_directories is a mistake because the 'gdal' include subdirectory needs to be added when FlightGear is compiling with GDAL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is supposed to happen automatically: becuase we declare GALD as a PUBLIC dependency of Simgear:
target_link_libraries(SimGearScene PUBLIC GDAL::GDAL)
... then anything that links against SimGear will get the INCLUDE properties declared by the GDAL imported target automatically. So the current code is already correct in theorey: we just need to work out why it's not worked as designed.
Adding 'include_directory' manual is a work-around, but not the correct fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I found the issue. FlightGear was not able to get the
include directory using the module GDAL::GDAL (see
flightgear/CMakeModules/SetupFGFSLibraries.cmake line 80): may be this
could be fixed (not sure it's even possible). For this reason, I've to
add the include path and the lib with the path to
simgear/CMakeLists.txt. This is already done like that for other
libraries.
This is supposed to happen automatically: becuase we declare GALD as
a PUBLIC dependency of Simgear:
target_link_libraries(SimGearScene PUBLIC GDAL::GDAL)
... then anything that links against SimGear will get the INCLUDE
properties declared by the GDAL imported target automatically. So the
current code is already correct in theorey: we just need to work out
why it's not worked as designed.
Adding 'include_directory' manual is a work-around, but not the
correct fix.
** [codetickets:#2608] Compilation issues with CycloneDDS and GDAL
(fix provided)**
Status: New Milestone: None Labels: GDAL CycloneDDS Created: Mon Jul 05, 2021 06:53 AM UTC by Gaétan Allaert Last Updated: Thu Jul 29, 2021 09:19 AM UTC Owner: nobody Attachments:
--
||/ There are only 10 kinds of people:
/~ ~\ -Those who understand binary
|@ @| -Those who don't
|-oooO----(_)---Oooo---------------------------------------|
Gaétan Allaert
DDS fix is fine.
For GDAL, I am clueless: what is official correct: with the <gdal/ or without? Becuase inside SGDemTile_gdal.cxx, we have:
include <gdal.h>
include <gdalwarper.h>
include <gdal_priv.h></gdal_priv.h></gdalwarper.h></gdal.h>
So I would soner we use same path for all GDAL includes, otherwise life is tricky...
Hi James,
Actually it is better not to add 'gdal/' in the source code as FindGDAL.cmake module provides the full include path with gdal/ included.
|I've attached another patch that also fix the same issue in FlightGear but part of SimGear.
I've done some checking: FindGDal indeed sets the directory with the full path as you wrote, so the #includes in SGDemTile.hxx are correct.
Using include_directories() is no longer good CMake practice. The GDAL dependenyc is supposed to be handled by this logic in SimGear.cmake.in:
set(ENABLE_GDAL @ENABLE_GDAL@)
if (ENABLE_GDAL)
find_dependency(GDAL)
endif()
... which should find GDAL when Simgear is imported into FlightGear, if GDAL is enabeld of course.
Can you post the build errors you are seeing in FlightGear? You can also edit the installed SimGear.cmake (probabyl lives at /use/local/lib/cmake/SimGear/SimgearConfig.cmake) to check it looks correct, eg the @ substituion worked.
When I remove the include_directories of GDAL_INCLUDE_DIRS from the generated lib/cmake/SimGear/SimGearConfig.cmake, <gdal.h> can't be found when compiling flightgear/src/Airports/AirportBuilder.cxx:41.</gdal.h>
My manually modified lib/cmake/SimGear/SimGearConfig.cmake:
The error from the compiler is:
I don't think adding include_directories is a mistake because the 'gdal' include subdirectory needs to be added when FlightGear is compiling with GDAL.
This is supposed to happen automatically: becuase we declare GALD as a PUBLIC dependency of Simgear:
... then anything that links against SimGear will get the INCLUDE properties declared by the GDAL imported target automatically. So the current code is already correct in theorey: we just need to work out why it's not worked as designed.
Adding 'include_directory' manual is a work-around, but not the correct fix.
Hi James,
I think I found the issue. FlightGear was not able to get the
include directory using the module GDAL::GDAL (see
flightgear/CMakeModules/SetupFGFSLibraries.cmake line 80): may be this
could be fixed (not sure it's even possible). For this reason, I've to
add the include path and the lib with the path to
simgear/CMakeLists.txt. This is already done like that for other
libraries.
I've attached the patch.
On Thu, 29 Jul 2021 09:35:19 -0000
"James Turner" jmturner@users.sourceforge.net wrote:
--
||/ There are only 10 kinds of people:
/~ ~\ -Those who understand binary
|@ @| -Those who don't
|-oooO----(_)---Oooo---------------------------------------|
Gaétan Allaert
Key server : https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event
Key ID : 55472127
Related
Tickets: #2608
Hi Gaétan, is this still an issue with the current code state? If not, we can close it.
Note that we plan to remove GDAL support on next, unless someone wants to maintain it. It will remain on 2024.1 branch, however.