[gdal-dev] Why can't find_package(GDAL CONFIG) find GDAL_LIBRARIES?

Tue Jun 7 10:58:26 PDT 2022

Hi Even, 

You write: 
> There's no universal way however of knowing the X::Y target name for a random package. You have to consult each package's documentation. 

Where is this typically documented? For example, where can I find GDAL package documentation? I looked in the [ https://gdal.org/gdal.pdf | main GDAL document ] but didn't find it there (I might have missed it there...) 

Thanks! 
Tom 
-------------------------------------------------- 
Thomas C. O'Reilly 
Monterey Bay Aquarium Research Institute 
7700 Sandholdt Road 
Moss Landing, California 95039-9644 
831-775-1766 (voice) 
831-775-1620 (FAX) 
oreilly at mbari.org (email) 
http://www.mbari.org (World-wide Web) 

"The machine does not isolate us from the great mysteries 
of nature, but plunges us more deeply into them." 

- ANTOINE DE SAINT-EXUPERY 
"Wind, Sand, and Stars" (1939) 

From: "Even Rouault" <even.rouault at spatialys.com> 
To: "Tom O'Reilly" <oreilly at mbari.org> 
Cc: "gdal-dev" <gdal-dev at lists.osgeo.org> 
Sent: Tuesday, June 7, 2022 10:10:26 AM 
Subject: Re: [gdal-dev] Why can't find_package(GDAL CONFIG) find GDAL_LIBRARIES? 

That becomes slightly out-of-topic, but CMake practices have evolved over time. Having depencies expressed from target name is indeed more elegant/powerful. There's no universal way however of knowing the X::Y target name for a random package. You have to consult each package's documentation. One good reason is that the same package can expose several targets (sub-components, shared vs static, etc.) 
Le 07/06/2022 à 18:52, Tom O'Reilly a écrit : 

Thanks for this information Even - very useful and interesting. 

I'm still a cmake newbie, and one cmake aspect that drives me nuts is its "inconsistency" when it comes to finding packages ("Should I call find_package(X) with MODULE or CONFIG?", "Is it X_INCLUDE_DIRS or X_INCLUDES?"). So my CMakeLists.txt tend to get complex pretty quickly. 

The method you describe looks elegant and straightforward, and it works for GDAL. In general for package 'X', is the following *guaranteed* to produce a usable target of form "X::X" or exit if package X is not found? 

BQ_BEGIN

# Find package X 
find_package(X CONFIG REQUIRED) 

add_executable(test_c test_c.c) 
target_link_libraries(test_c PRIVATE X::X) 

If I could rely on that form, my CMakeLists.txt files would be much simpler! 

Thanks 
Tom 

-------------------------------------------------- 
Thomas C. O'Reilly 
Monterey Bay Aquarium Research Institute 
7700 Sandholdt Road 
Moss Landing, California 95039-9644 
831-775-1766 (voice) 
831-775-1620 (FAX) 
[ mailto:oreilly at mbari.org | oreilly at mbari.org ] (email) 
[ http://www.mbari.org/ | http://www.mbari.org ] (World-wide Web) 

"The machine does not isolate us from the great mysteries 
of nature, but plunges us more deeply into them." 

- ANTOINE DE SAINT-EXUPERY 
"Wind, Sand, and Stars" (1939) 

From: "Even Rouault" [ mailto:even.rouault at spatialys.com | <even.rouault at spatialys.com> ] 
To: "Tom O'Reilly" [ mailto:oreilly at mbari.org | <oreilly at mbari.org> ] , "gdal-dev" [ mailto:gdal-dev at lists.osgeo.org | <gdal-dev at lists.osgeo.org> ] 
Sent: Tuesday, June 7, 2022 12:28:42 AM 
Subject: Re: [gdal-dev] Why can't find_package(GDAL CONFIG) find GDAL_LIBRARIES? 

Tom, 

GDAL_LIBRARIES and GDAL_INCLUDE_DIRS are indeed not defined. You have to use the "GDAL::GDAL" target in a 
target_link_libraries() statement which propagates both include and linking requirements and tends to be the modern CMake practice, although admitedly not very clearly documented in target_link_libraries() official documentation. I found [ https://schneide.blog/2016/04/08/modern-cmake-with-target_link_libraries/ | https://schneide.blog/2016/04/08/modern-cmake-with-target_link_libraries/ ] which deal with that. 

So a typical minimum CMakeLists.txt of a project using GDAL is (this is actually [ https://github.com/OSGeo/gdal/blob/master/autotest/postinstall/test_c/CMakeLists.txt | https://github.com/OSGeo/gdal/blob/master/autotest/postinstall/test_c/CMakeLists.txt ] used in GDAL continuous integration to test usage of GDAL from a third-party library/application) 

""" 

cmake_minimum_required(VERSION 3.0) 

project(test_c C CXX) # CXX for properly linking GDAL 

find_package(GDAL CONFIG REQUIRED) 

add_executable(test_c test_c.c) 
target_link_libraries(test_c PRIVATE GDAL::GDAL) 

""" 

I've created [ https://github.com/OSGeo/gdal/issues/5875 | https://github.com/OSGeo/gdal/issues/5875 ] to track we need documenting that. 

Note: If you really wanted to get the equivalent of GDAL_INCLUDE_DIRS and GDAL_LIBRARIES, you could use the following expressions: 

$<TARGET_PROPERTY:GDAL::GDAL,INTERFACE_INCLUDE_DIRECTORIES> 

$<TARGET_PROPERTY:GDAL::GDAL,INTERFACE_LINK_LIBRARIES> 

Even 

Le 07/06/2022 à 02:02, Tom O'Reilly a écrit : 

BQ_BEGIN

I've just built and installed GDAL 3.5.0 on ubuntu 20.04, with cmake 3.5.0 and make. It appears that 'make install' installs needed cmake config files for GDAL: 

BQ_BEGIN

-- Installing: /usr/local/lib/x86_64-linux-gnu/cmake/gdal/GDALConfigVersion.cmake 
-- Installing: /usr/local/lib/x86_64-linux-gnu/cmake/gdal/GDALConfig.cmake 

BQ_END

I'm building my own project that uses GDAL. The CMakelists.txt invokes find_package() and prints out resulting variables: 

BQ_BEGIN

find_package(GDAL CONFIG REQUIRED) 

if (GDAL_FOUND) 
message("GDAL Found!") 
message("GDAL_INCLUDE_DIRS: ${GDAL_INCLUDE_DIRS}") 
message("GDAL_LIBRARIES: ${GDAL_LIBRARIES}") 
message("GDAL_VERSION: ${GDAL_VERSION}") 
else() 
message("GDAL not found") 
endif() 

BQ_END

Running cmake indicates that GDAL_FOUND is true, GDAL_VERSION is set to the expected value(3.5.0), but GDAL_LIBRARIES and GDAL_INCLUDE_DIRS are empty: 

BQ_BEGIN

GDAL Found! 
GDAL_INCLUDE_DIRS: 
GDAL_LIBRARIES: 
GDAL_LIBRARY: 
GDAL_VERSION: 3.5.0 

BQ_END

Why are GDAL_LIBRARIES and GDAL_INCLUDE_DIR empty? 

Thanks 
Tom 

BQ_BEGIN

BQ_END

-------------------------------------------------- 
Thomas C. O'Reilly 
Monterey Bay Aquarium Research Institute 
7700 Sandholdt Road 
Moss Landing, California 95039-9644 
831-775-1766 (voice) 
831-775-1620 (FAX) 
[ mailto:oreilly at mbari.org | oreilly at mbari.org ] (email) 
[ http://www.mbari.org/ | http://www.mbari.org ] (World-wide Web) 

"The machine does not isolate us from the great mysteries 
of nature, but plunges us more deeply into them." 

- ANTOINE DE SAINT-EXUPERY 
"Wind, Sand, and Stars" (1939) 

_______________________________________________
gdal-dev mailing list [ mailto:gdal-dev at lists.osgeo.org | gdal-dev at lists.osgeo.org ] [ https://lists.osgeo.org/mailman/listinfo/gdal-dev | https://lists.osgeo.org/mailman/listinfo/gdal-dev ] 

BQ_END

-- [ http://www.spatialys.com/ | http://www.spatialys.com ] My software is free, but my time generally not. 

BQ_END

-- [ http://www.spatialys.com/ | http://www.spatialys.com ] My software is free, but my time generally not. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220607/75335169/attachment.htm>