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

Use FIND_LIBRARY to find GDAL, GEOS and Postgres libraries #6171

Merged

Conversation

landryb
Copy link
Contributor

@landryb landryb commented Jan 25, 2018

On OpenBSD, there's no libgdal.so symlink, only a versioned library (ie
libgdal.so.X.Y where X.Y changes over time so is never constant)
Using cmake's FIND_LIBRARY allows to let cmake find the library.

Without this, the build would fail on OpenBSD:
ninja: error: '/usr/local/lib/libgdal.so', needed by 'output/lib/libqgis_core.so.18.0', missing and no known rule to make it

Description

I'm not sure the linux distros end up in this cmake codepath, but it should cause no regressions there, and allows me to upstream 3 patches i've been carrying since years (cf http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/geo/qgis/patches/patch-cmake_FindGDAL_cmake?rev=1.10&content-type=text/x-cvsweb-markup , http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/geo/qgis/patches/patch-cmake_FindGEOS_cmake?rev=1.11&content-type=text/x-cvsweb-markup and http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/geo/qgis/patches/patch-cmake_FindPostgres_cmake?rev=1.9&content-type=text/x-cvsweb-markup - those patches were OpenBSD-specific with LOCALBASE, but the PR reuses the paths provided by the cmake module)

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

  • Commit messages are descriptive and explain the rationale for changes
  • Commits which fix bugs include fixes #11111 in the commit message next to the description
  • Commits which add new features are tagged with [FEATURE] in the commit message
  • Commits which change the UI or existing user workflows are tagged with [needs-docs] in the commit message and containt sufficient information in the commit message to be documented
  • I have read the QGIS Coding Standards and this PR complies with them
  • This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
  • New unit tests have been added for core changes
  • I have run the scripts/prepare-commit.sh script before each commit

On OpenBSD, there's no libgdal.so symlink, only a versioned library (ie
libgdal.so.X.Y where X.Y changes over time so is never constant)
Using cmake's FIND_LIBRARY allows to let cmake find the library.

Without this, the build would fail on OpenBSD:
ninja: error: '/usr/local/lib/libgdal.so', needed by 'output/lib/libqgis_core.so.18.0', missing and no known rule to make it
@landryb
Copy link
Contributor Author

landryb commented Jan 25, 2018

@lbartoletti you probably don't need this as FreeBSD has the libfoo.so symlinks iirc, but this should cause no regression for you.

Im still unsure if only the BSDs endup in the cmake IF UNIX BUT NOT APPLE paths.. anyone knowing well the qgis cmake internals would know ?

@lbartoletti
Copy link
Member

Great!
Works also on FreeBSD 👍 😉

@jef-n jef-n merged commit bf3d60c into qgis:master Jan 30, 2018
@landryb landryb deleted the fix/find-gdal-geos-postgres-libs-on-openbsd branch January 30, 2018 16:01
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.

None yet

3 participants