Date: Wed, 21 Feb 2024 21:19:38 +0000 From: bugzilla-noreply@freebsd.org To: java@FreeBSD.org Subject: [Bug 277204] *: ports misusing WITH_CCACHE_BUILD and NO_CCACHE Message-ID: <bug-277204-8522-O8YC22DLNR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277204-8522@https.bugs.freebsd.org/bugzilla/> References: <bug-277204-8522@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277204 --- Comment #3 from Matthias Andree <mandree@FreeBSD.org> --- Gleb, thanks for looking at rawtherapee. I have 5.10 cooking, test compiles= on the off-versions got delayed due to the usual rust rebuild madness (because= the upstream package for 13.2 wasn't up to date with the port), and I successiv= ely tried getting rid of all that you criticize. The thing about rawtherapee is, we don't have OpenCL, but only OpenMP, and = it is computationally VERY expensive (as raw camera image processing is in general, with Bayer/Foveon/TransX demosaicing, denoising and thereabouts), = so we need to squeeze every bit out of the CPU that we can. RT would currently build against GCC 12.3 on amd64, even without too many of the force options, so... - we should use LTO because upstream recommends it and it seems to increase performance on cross-compilation-unit calls, - which incurs the forcing of binutils to avoid linker failures, - we need to work around our cmake not being ccache friendly, because - bei= ng written in mostly C++ - rawtherapee is slow enough to compile (and I could argue that our ccache.mk is broken if it sets CCACHE_ENABLE so late that I can't derive CMAKE_ARGS with a simple .if... - it only gets set in the "pos= t" phase, not in port.options.mk, not in port.pre.mk) - last time I tried, run-time performance with LLVM compiler was inferior to GCC's (might be worth retrying, but that would delay the RT 5.10 upgrade to= at least next week or the week after) and I'm not sure what the state of libst= dc++ vs. libc++ affairs currently is. Smoke-testing in post-install is something I found necessary on my end beca= use there used to be builds that would crash on start, and I don't want them to escape my testing. Without test images in the source folder, these will be skipped. Unfortunately, poudriere has no support to run "make test" and dep= ends properly for "poudriere bulk" and "poudriere testport".=20 Arguably I could try to provide such stuff for .mk scripts now that some of= the people who were constantly getting in my way or asking for perfection inste= ad of an -exp run are no longer part of portmgr@ and haven't been seen as part= of the project in a long time, but that, too, is beyond my available time right now. Back to the rawtherapee 5.10 topic, I can remove some things, but none of t= he "lighter" ccache approaches would actually use ccache to build, so the ccac= he variable abuse that Benjamin pointed out cannot be fixed yet, I've tried th= at. Anything but the way it's written currently ends up with a hard-coded /usr/local/bin/g++12 as a compiler (with hardcoded path, so we can't BINARY_ALIAS or play PATH tricks) as a result of the cmake run, and what the port currently does seems to be one of the official cmake ways to get ccache into play. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277204-8522-O8YC22DLNR>