[gdal-dev] Why can't find_package(GDAL CONFIG) find GDAL_LIBRARIES?
Even Rouault
even.rouault at spatialys.com
Tue Jun 7 10:10:26 PDT 2022
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?
>
> # 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)
> 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>, "gdal-dev"
> <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/
> 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
> 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 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 :
>
> 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:
>
> -- Installing:
> /usr/local/lib/x86_64-linux-gnu/cmake/gdal/GDALConfigVersion.cmake
> -- Installing:
> /usr/local/lib/x86_64-linux-gnu/cmake/gdal/GDALConfig.cmake
>
> I'm building my own project that uses GDAL. The CMakelists.txt
> invokes find_package() and prints out resulting variables:
>
> 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()
>
> 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:
>
> GDAL Found!
> GDAL_INCLUDE_DIRS:
> GDAL_LIBRARIES:
> GDAL_LIBRARY:
> GDAL_VERSION: 3.5.0
>
> Why are GDAL_LIBRARIES and GDAL_INCLUDE_DIR empty?
>
> 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)
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
--
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/fa0f7936/attachment-0001.htm>
More information about the gdal-dev
mailing list