Created attachment 232823 [details] [New Port] graphics/lux: Panorama and image viewer lux is an image viewer for 'normal' images and the most common types of panoramic images, typically showing a 'rectilinear' view to the image data, which looks as if this view had been taken with an 'ordinary' lens. The view can be zoomed, panned, scrolled, rotated and modified in several ways. lux displays images, it does not modify them. But it can produce high-quality images from the view it shows. lux can also produce synoptic views of several images and do stitching, HDR blending, exposure fusions, focus stacks and deghosting, usually from 'PTO' files, processing a subset of the panotools standard used by panorama stitching software like hugin. WWW: https://bitbucket.org/kfj/pv Tested with Poudriere on i386 amd64 armv7 arm64 FreeBSD 12 and 13. Does not currently build natively on armv7 due to an OOM condition in the C compiler. It should build with native xtools though. Portlint and portclippy like the port. There's a -Ofast in the CMakeLists file. I'm not sure what the policy about potentially flaky compiler options like this one is.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=60c597255369b19614c7430ad6d7a158c0df3cfe commit 60c597255369b19614c7430ad6d7a158c0df3cfe Author: Robert Clausecker <fuz@fuz.su> AuthorDate: 2022-03-18 23:09:02 +0000 Commit: Mikael Urankar <mikael@FreeBSD.org> CommitDate: 2022-04-01 05:38:53 +0000 graphics/lux: Add new port lux is an image viewer for 'normal' images and the most common types of panoramic images, typically showing a 'rectilinear' view to the image data, which looks as if this view had been taken with an 'ordinary' lens. The view can be zoomed, panned, scrolled, rotated and modified in several ways. lux displays images, it does not modify them. But it can produce high-quality images from the view it shows. lux can also produce synoptic views of several images and do stitching, HDR blending, exposure fusions, focus stacks and deghosting, usually from 'PTO' files, processing a subset of the panotools standard used by panorama stitching software like hugin. WWW: https://bitbucket.org/kfj/pv PR: 262943 graphics/Makefile | 1 + graphics/lux/Makefile (new) | 43 ++++++++++++++++++++++++ graphics/lux/distinfo (new) | 3 ++ graphics/lux/files/patch-CMakeLists.txt (new) | 22 ++++++++++++ graphics/lux/files/patch-tinyfiledialogs.c (new) | 16 +++++++++ graphics/lux/pkg-descr (new) | 12 +++++++ 6 files changed, 97 insertions(+)
Thanks!
MASTER_SITES= https://bitbucket.org/kfj/pv/get/${DISTVERSION}.tar.bz2?dummy=/ Seems to work and generates better distname ? Preferably fonts should use a separate package and go into ${FONTSDIR} Regarding -Ofast it's covered here in Porters Handbook https://docs.freebsd.org/en/books/porters-handbook/book/#dads-cflags
(In reply to Daniel Engberg from comment #3) Hello Daniel, Thank you for your comments. I had considered modifying the distribution file name but had decided against it as the current distribution file name is already unique. As for the fonts, I am considering to make a separate port just for it. The section about CFLAGS does not say anything specific about -Ofast.
(In reply to Robert Clausecker from comment #4) Hi, While it is unique I think there certainly is value in easily being able to identify a distfile by hand. If you scale up on that reasoning and say you have 100+ ports doing the same thing you _may_ end up with unnecessary clashing and for sure confusion. Regarding CFLAGS optimization we handle that using OPTIMIZED_CFLAGS menu option [1] but not by default and only if it makes sense (when there's a measurable difference not impacting functionality). If I'm not misremembering the major difference between O3 and Ofast is that the latter enables -ffast-math which can be a bit flakey so if O3 makes just as much difference I think it's better to go with that instead. [1] https://github.com/freebsd/freebsd-ports/blob/main/Mk/bsd.options.desc.mk#L389