[Bug 297886] emulators/ares wrong BUILD_DEPENDS
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 297886] emulators/ares wrong BUILD_DEPENDS"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 25 Aug 2026 10:52:36 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297886
--- Comment #3 from Stefan Schlosser <bsdcode@disroot.org> ---
Hi Marcel,
I guess you still have librashader installed in your build environment and
that's why your build still succeeds with the BUILD_DEPENDS removed. If I
remove it (and disable the LIBRASHADER port option) and try to build the port
in a clean build environment, make configure is erroring out:
$ make configure
===> License ISCL accepted by the user
===> Fetching all distfiles required by ares-148_4 for building
===> Extracting for ares-148_4
=> SHA256 Checksum OK for ares/148/ares-source.tar.gz.
===> Patching for ares-148_4
===> Applying FreeBSD patches for ares-148_4 from
/usr/ports/emulators/ares/files
/usr/bin/env WRKSRC=/usr/ports/emulators/ares/work/ares-148_4
REWARNFILE=/usr/ports/emulators/ares/work/reinplace_warnings.txt /bin/sh
/usr/ports/Mk/Scripts/sed_checked.sh 's|/usr/local|/usr/local|g'
/usr/ports/emulators/ares/work/ares-148_4/cmake/finders/*
===> Configuring for ares-148_4
===> Performing out-of-source build
/bin/mkdir -p /usr/ports/emulators/ares/work/.build
-- The C compiler identification is Clang 19.1.7
-- The CXX compiler identification is Clang 19.1.7
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/libexec/ccache/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/libexec/ccache/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Trying to find Ccache on build host
-- Trying to find Ccache on build host - success
-- Ccache enabled - located at /usr/local/bin/ccache
-- Checking if interprocedural optimization is supported
-- Checking if interprocedural optimization is supported - success
-- Found PkgConfig: /usr/local/bin/pkgconf (found version "3.0.5")
-- Checking for module 'libchdr'
-- Found libchdr, version 0.3.0
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found X11: /usr/local/include
-- Looking for XOpenDisplay in
/usr/local/lib/libX11.so;/usr/local/lib/libXext.so
-- Looking for XOpenDisplay in
/usr/local/lib/libX11.so;/usr/local/lib/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found OpenGL: /usr/local/lib/libOpenGL.so
-- Checking for one of the modules 'librashader'
CMake Warning (dev) at cmake/finders/Findlibrashader.cmake:83 (message):
Failed to find librashader version.
Call Stack (most recent call first):
ruby/cmake/os-freebsd.cmake:40 (find_package)
ruby/CMakeLists.txt:40 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Could NOT find librashader (missing: librashader_LIBRARY) (found version
"0.0.0")
Reason given by package: Ensure librashader libraries are available in
local library paths.
-- Found OpenAL: /usr/local/lib/libopenal.so
-- Found SDL: /usr/local/lib/libSDL3.so (found version "3.4.14")
-- Found OSS: /usr/include (found version "15.0-RELEASE-p12")
-- Found ALSA: /usr/local/lib/libasound.so (found version "1.2.16.1")
-- Found AO: /usr/local/lib/libao.so
-- Found udev: /usr/local/lib/libudev.so
-- Found usbhid: /usr/include (found version "15.0-RELEASE-p12")
-- Found GTK: /usr/local/lib/libgtk-3.so (found version "3.24.52")
..
::.
.::. ____ _________ _____
.. .:::. / __ `/ ___/ _ \/ ___/
.-:::::::: / /_/ / / / __(__ )
.::::. \__,_/_/ \___/____/
ares version: v148 (0.148.0)
==================================================================================
------------------------ Enabled Features
------------------------
- ALSA audio driver
- AO audio driver
- CHD format support via libchdr
- GLX OpenGL video driver
- GTK3 UI backend
- N64 Vulkan rendering with paraLLEl-RDP
- OSS audio driver
- OpenAL audio driver
- SDL audio driver
- SDL input driver
- Xlib input driver
- udev input driver
- usbhid input driver
------------------------ Disabled Features
------------------------
- PulseAudio audio driver
------------------------ Enabled Cores
------------------------
- Atari 2600
- ColecoVision
- Game Boy / Game Boy Color
- Game Boy Advance
- Microsoft MSX
- My Vision
- NES / Famicom
- Neo Geo (AES/MVS)
- Neo Geo Pocket / Neo Geo Pocket Color
- Nintendo 64
- PC-Engine / TurboGrafx
- PlayStation
- SNES / Super Famicom
- Sega Master System / Mark III
- Sega Mega Drive / Genesis
- Sega SG-1000
- WonderSwan / WonderSwan Color
- ZX Spectrum
------------------------ Disabled Cores
------------------------
- Sega Saturn
----------------------- Enabled Subprojects
----------------------
- sourcery (resource compiler)
----------------------- Disabled Subprojects
----------------------
- arm7tdmi processor test harness
- genius (database editor)
- i8080 processor test harness
- m68000 processor test harness
- mame2bml (MAME manifest converter)
- mia (manifest generator) standalone frontend
==================================================================================
-- Configuring done (2.5s)
CMake Error at ruby/cmake/os-freebsd.cmake:130 (target_link_libraries):
Target "ruby" links to:
librashader::librashader
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Call Stack (most recent call first):
ruby/CMakeLists.txt:40 (include)
-- Generating done (0.1s)
CMake Warning:
Manually-specified variables were not used by the project:
ARES_BUNDLE_SHADERS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_VERBOSE_MAKEFILE
FETCHCONTENT_FULLY_DISCONNECTED
CMake Generate step failed. Build files cannot be regenerated correctly.
*** Error code 1
Stop.
make[1]: stopped making
"/usr/ports/emulators/ares/work/.configure_done.ares._usr_local" in
/usr/ports/emulators/ares
*** Error code 1
Stop.
make: stopped making "configure" in /usr/ports/emulators/ares
Ares always needs the librashader headers for compiling, regardless if the
shader support is requested or not. It would actually be a good thing to
untangle upstream, but for now, as it stands, ares needs the headers.
Ares bundles the librashader headers under its thirdparty/librashader
directory, and it provides a Findlibrashader.cmake finder module in
cmake/finders, which prioritizes looking for the headers at this location
first, and then at /usr/include and /usr/local/include second (the port
replaces the /usr/local with ${LOCALBASE} in all finder modules).
To honor port policies, I unbundled librashader with an unconditionally
BUILD_DEPENDS on the librashader port to provide the headers, and also don't
extract the thirdparty/librashader directory from the distfile with the help of
EXTRACT_AFTER_ARGS. This way, the port always uses the headers from the port.
Additionally, the port has a conditional LIB_DEPENDS on librashader if the
shader functionality should be compiled in.
Now, I do understand that you and maybe other port users don't like the
additional requirement for a rust compiler just for librashader. I can
sympathize.
We could remove the unconditional BUILD_DEPENDS on librashader and use the
bundled librashader headers if the LIBRASHADER option is disabled, and use the
port otherwise. This is possible because librashader is actually very committed
to providing a stable API, so using the bundled headers, which in general are
not from the latest librashader release, should be equally ok than to use the
headers from a more recent librashader release like what the librashader port
provides.
I will work out a patch for this, and we have to see if port
reviewers/committers are ok with this change following port policies and best
practices.
Best regards,
Stefan
--
You are receiving this mail because:
You are the assignee for the bug.