Page MenuHomeFreeBSD

graphics/lensfun: install lensfun-update-database and lensfun-add-adapter helpers
ClosedPublic

Authored by mandree on Dec 30 2016, 12:21 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 26, 1:15 PM
Unknown Object (File)
Jan 24 2026, 11:34 PM
Unknown Object (File)
Jan 22 2026, 4:11 AM
Unknown Object (File)
Jan 21 2026, 11:19 AM
Unknown Object (File)
Jan 20 2026, 10:15 PM
Unknown Object (File)
Jan 20 2026, 4:11 PM
Unknown Object (File)
Jan 19 2026, 2:15 PM
Unknown Object (File)
Dec 20 2025, 3:29 PM
Subscribers

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mandree retitled this revision from to graphics/lensfun: install lensfun-update-database and lensfun-add-adapter helpers.
mandree updated this object.
mandree edited the test plan for this revision. (Show Details)
mandree added a reviewer: danfe.
mandree set the repository for this revision to rP FreeBSD ports repository.

Matthias, can you elaborate a bit why these helper scripts are useful for end-users (not developers of lensun)? Particularly, I'm worried about pulling Python 3 dependency (at least unconditionally).

Do you have some consumer port that would require them and cannot work with existing databases lensfun provides for some reason? If so, it would be nice to know more about it.

The database

In D8993#185719, @danfe wrote:

Matthias, can you elaborate a bit why these helper scripts are useful for end-users (not developers of lensun)? Particularly, I'm worried about pulling Python 3 dependency (at least unconditionally).

Python 3 is sufficiently lightweight not to worry about, if someone runs darktable or other users of lensfun, you'll have heaviweight stuff on the system already.

The lens correction database is notoriously out of date, and lensfun-update-database downloads a current version (it figures out if it has privileges and either installs into the system directory, or in to $HOME/.local).

The only alternative I see is that we package the database in a separate lensfun-database package that gets updated as the upstream database gets updated - but will be notoriously out of date on the quarterly branch, too.

Do you have some consumer port that would require them and cannot work with existing databases lensfun provides for some reason? If so, it would be nice to know more about it.

No, I don't.

OK fair enough. I also don't think that adding another lensfun-database port is worth it. Please address inline comments and I think it's OK to commit.

Makefile
20 ↗(On Diff #23446)

Isn't STAGEDIR passed to CMake by default? Why explicit passing is required in this place?

files/patch-CMakeLists.txt
1 ↗(On Diff #23446)

Touching the patch file just because of timestamp change is bogus, please exclude it from the commit batch.

I'll also add an option so as to remove the Python dependency, but default it to "on" because we don't want to maintain a separate lensfun-database port.

Makefile
20 ↗(On Diff #23446)

It's not passed in a way that cmake would expose it to its command (but might be my ignorance of cmake), so that cmake would use it in the line that calls Python's distutils from within apps/CMakeLists.txt (see files/patch-apps_CMakeLists.txt that adds --root=${STAGEDIR}, such that the installation goes to the staging area rather than directly to the file system).

Unfortunately, USE_PYTHON=distutils would override the do-build/do-install targets so we can't use it. So without that -DSTAGEDIR... installation fails for non-root users (missing permission to write into ${PREFIX}) and pollutes the file system for privileged users.

files/patch-CMakeLists.txt
1 ↗(On Diff #23446)

sorry, "make makepatch" pollution. Will remove.

v2: make the Python helpers optional, but enable option by default (PYHELPERS option).

This adds -DPYTHON:STRING=IGNORE in the "off" case, because otherwise lensfun would still build (even if it doesn't stage/install them) the scripts when building in a live system (portmaster, portupgrade, "make -C $PORTSDIR/graphics/lensfun".)

We need to pass -DSTAGEDIR:STRING=... because the cmake.mk rig isn't exposing STAGEDIR as a cmake variable, and using $ENV{STAGEDIR} didn't work either (because MAKE_ENV or MAKE_ARGS are not setting STAGEDIR either) so since we set it explictly, we can as well export it directly to cmake.

Do not touch files/patch-* to only update timestamps.

This revision was automatically updated to reflect the committed changes.