Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: new(ish) devel/sdl3
To:
Omar Polo <op@omarpolo.com>
Cc:
ports@openbsd.org, Thomas Frohwein <tfrohwein@fastmail.com>
Date:
Fri, 1 Aug 2025 10:48:02 +0100

Download raw body.

Thread
  • Omar Polo:

    new(ish) devel/sdl3

  • On 2025/08/01 11:06, Omar Polo wrote:
    > Stuart Henderson <stu@spacehopper.org> wrote:
    > > On 2025/07/31 17:46, Omar Polo wrote:
    > > > Hello,
    > > > 
    > > > This is thfr' devel/sdl3 port but with the version bumped.
    > > > 
    > > > I need it for updating games/taisei.  I can testify that it works :)
    > > > 
    > > > 
    > > 
    > > I think it's ok to import this, but be prepared to deal with any SDL 2
    > > ports which might start picking it up. I think I've disabled that in
    > > something before but there may be others.
    > > 
    > > Ideally test with a 'mini bulk' with this already installed and
    > > run port-lib-depends-check first, though I appreciate there a quite a
    > > lot of ports, it might at least be worth doing a sample (perhaps the
    > > more recently updated ones?).
    > > 
    > > I usually construct a list from grep [...] ports-INDEX | cut -d\| -f2,
    > > edit then point SUBDIRLIST at it, e.g. something along these lines
    > > 
    > > cd /usr/ports
    > > SUBDIRLIST=/path/to/list make prepare FETCH_PACKAGES=
    > > SUBDIRLIST=/path/to/list make package REPORT_PROBLEM=/usr/bin/true
    > > SUBDIRLIST=/path/to/list make port-lib-depends-check REPORT_PROBLEM=/usr/bin/true
    > > 
    > > (setting REPORT_PROBLEM like this stops it from killing the build at
    > > the first error)
    > 
    > thanks again for the pointers! :)
    > 
    > I did a tinybulk with some ports to judge the impact, but either the
    > impact is small or my selection is bad.  Here's the result
    > 
    > $ SUBDIRLIST=/usr/ports/mylist make port-lib-depends-check REPORT_PROBLEM=/usr/bin/true
    > ===> games/fna/faudio
    > ===> games/fna/fna
    > ===> games/fna/fna3d
    > ===> graphics/ffmpeg
    > ===> emulators/retroarch
    > ===> games/scummvm
    > 
    > scummvm-2.9.1(games/scummvm):
    > Extra:  iconv.7
    > ===> games/love/0.10
    > 
    > love-0.10.2p3(games/love/0.10):
    > Missing: iconv.7 from libiconv-1.17 (/usr/local/lib/liblove-0.10.2.so.0.0)
    > WANTLIB += iconv
    > *** Error 1 in target 'port-lib-depends-check' (ignored)
    > ===> games/love/0.8
    > 
    > love-0.8.0p17(games/love/0.8):
    > Missing: LLVM.9 (/usr/local/bin/love-0.8) (system lib)
    > Missing: drm_amdgpu.1 (/usr/local/bin/love-0.8) (system lib)
    > Missing: drm_intel.5 (/usr/local/bin/love-0.8) (system lib)
    > Missing: elf.3 (/usr/local/bin/love-0.8) (system lib)
    > Missing: pciaccess.2 (/usr/local/bin/love-0.8) (system lib)
    > WANTLIB += LLVM drm_amdgpu drm_intel elf pciaccess
    > *** Error 1 in target 'port-lib-depends-check' (ignored)
    > ===> games/love/11
    > 
    > love-11.5p2(games/love/11):
    > Missing: iconv.7 from libiconv-1.17 (/usr/local/lib/liblove-11.5.so.0.0)
    > WANTLIB += iconv
    > *** Error 1 in target 'port-lib-depends-check' (ignored)
    > ===> net/lagrange
    > ===> multimedia/shotcut
    > ===> graphics/krita
    > 
    > these wantlib changes I think are already there (i'm a bit confused by
    > love and why it picks up those libraries tbf) but since they don't
    > mention sdl3 I *guess* they're unrelated.
    
    yes, unrelated. they come from some other library depended on by thise
    ports, which started pulling in those additional libraries. some are
    a little problematic as they're arch-dependent e.g. drm_intel is only
    on i386/amd64, LLVM.9 only on base-gcc archs, and we don't have a good
    way to deal with that. (iconv is due to iirc a change in gettext).
    
    I synced up some of these recently (concentrating on ports where
    packages were totally broken due to no LIB_DEPENDS chain to a library
    they needed, and missing base libs - c/pthread) but there are bunch left.
    
    The port that I remembered preemptively disabling sdl3 (until ready to
    change) was fluidsynth, btw.
    
    > Regarding the wayland thing, I don't have a strong opinion.  I just took
    > thfr@ port since I needed to try updating and debugging an issue with
    > lto in games/taisei.  I haven't looked yet into (what kind of pain)
    > enabling wayland support is.
    
    tbh I think it's a bit of a distraction and it won't cause issues to
    punt it to later. the important thing is to make sure it is either
    explicitly disabled or enabled and not let it autodetect because that
    will break bulk builds during junking (and some of the wayland-related
    ports are header only so are hard to detect; port-lib-depends-check
    won't help for wayland-protocols for example).
    
    
  • Omar Polo:

    new(ish) devel/sdl3