[Bug 281080] emulators/ares: update to 139.20240825 and unbundle librashader dependency

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281080

--- Comment #2 from Stefan Schlosser <bsdcode@disroot.org> ---
The relationship between ares and librashader is this: ares bundles a local
copy of the complete librashader sourcecode under
${WRKSRC}/thirdparty/librashader. The only things ares really needs and uses
from it are the includefiles include/librashader.h and
include/librashader_ld.h. But this is mandatory, ares won't compile without
them. At runtime it isn't a hard dependency, it tries to dynamically load
${LOCALBASE}/lib/librashader.so and if it succeeds then shaders work, if it
doesn't succeed then shaders don't work.

If it wouldn't be an unconditional build dependency then we could control
everything related to librashader behind the SHADER portoption, i.e.
 * use SHADER_LIB_DEPENDS=devel/librashader instead of BUILD_DEPENDS +
SHADER_RUN_DEPENDS
 * use SHADER_CFLAGS=-DLIBRA_RUNTIME_OPENGL instead of CFLAGS
 * use ${REINPLACE_CMD} for librashader_ld.h in post-patch-SHADER-on instead of
in post-patch
 * use ${REINPLACE_CMD} 's|-I../thirdparty/librashader/include||g'
${WRKSRC}/desktop-ui/GNUmakefile in post-patch-SHADER-on instead of inside the
desktop-ui_GNUmakefile patch itself

Now, we can do exactly this, but because librashader is an unconditional build
dependency we have the following situation:
 * SHADER on: ares build uses includefiles from devel/librashader
 * SHADER off: ares build uses bundled includefiles

With my current updatepatch we just always use the includefiles from
devel/librashader.

What are you recommending?

-- 
You are receiving this mail because:
You are the assignee for the bug.