Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make PROJ the CMake project name addressing first stage of #1885 #1910

Merged
merged 1 commit into from Feb 5, 2020

Conversation

cffk
Copy link
Contributor

@cffk cffk commented Feb 4, 2020

Allow both find_package(PROJ) and find_package(PROJ4). More details
are in cmake/CMakeLists.txt.

  • Closes #1885 (first stage only)
  • Added clear title that can be used to generate release notes
  • Fully documented, including updating docs/source/*.rst for new API

Allow both find_package(PROJ) and find_package(PROJ4).  More details
are in cmake/CMakeLists.txt.
hobu
hobu approved these changes Feb 4, 2020
@rouault
Copy link
Member

@rouault rouault commented Feb 4, 2020

Slightly out of topic thoughts:

  • Do we have testing of find_package(PROJ) in the CI ? Would be cool if there was some dummy cmake project that would try to find PROJ with the proj-config.cmake file we generate.
  • By the way is it expected that this .cmake file is only generated with PROJ cmake builds ? That means that, in distributions building PROJ with autoconf, cmake projects cannot import PROJ.

@mwtoews
Copy link
Member

@mwtoews mwtoews commented Feb 4, 2020

  • Do we have testing of find_package(PROJ) in the CI ?

I've been thinking the same. It would be easiest to test in the CI script after install, as I don't think it's possible to do this with CTest.

  • By the way is it expected that this .cmake file is only generated with PROJ cmake builds ? That means that, in distributions building PROJ with autoconf, cmake projects cannot import PROJ.

Having just looking at this in #1484 it seems that only CMake builds can use find_package, and that Debian and Homebrew distributions don't bundle these files as they are Autotools-built.

@cffk
Copy link
Contributor Author

@cffk cffk commented Feb 5, 2020

Yes, some basic testing of find_package(PROJ) (+ PROJ4) should be tested in the CI. A more complete job would be testing the transitive inheritance of the dependency on PROJ.

I don't see how a decent job can be done providing config-style find_package support with autoconf without a lot of messy coding. I have done this with our builds of boost (before it got builtin support). But my solution was rather fragile and needed nursing along from version to version.

Conceivably someone has solved this problem already and there's a template to follow? I wish autoconf would fade into non-existence. (CMake certainly has its warts. But at least I can get most jobs done without a whole lot of fuss.)

  • Do we have testing of find_package(PROJ) in the CI ?

I've been thinking the same. It would be easiest to test in the CI script after install, as I don't think it's possible to do this with CTest.

  • By the way is it expected that this .cmake file is only generated with PROJ cmake builds ? That means that, in distributions building PROJ with autoconf, cmake projects cannot import PROJ.

Having just looking at this in #1484 it seems that only CMake builds can use find_package, and that Debian and Homebrew distributions don't bundle these files as they are Autotools-built.

@cffk cffk merged commit 1067766 into OSGeo:master Feb 5, 2020
4 checks passed
@kbevers kbevers added this to the 7.0.0 milestone Feb 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants