Re: games/love: bring in multiple versions
On 2023/02/13 12:59:50 -0500, Thomas Frohwein wrote: > On Mon, Feb 13, 2023 at 11:17:05AM +0100, Omar Polo wrote: > > On 2023/02/12 15:26:01 -0500, Thomas Frohwein > > wrote> > > A few WANTLIB seem to be missing for love 0.8: > > > > > > $ make port-lib-depends-check > > > > > > love-0.8.0p14(games/love/0.8): > > > Missing: Xau.10 (/usr/local/bin/love-0.8.0) (system lib) > > > Missing: Xdmcp.11 (/usr/local/bin/love-0.8.0) (system lib) > > > Missing: xcb-shm.1 (/usr/local/bin/love-0.8.0) (system lib) > > > Extra: Xdamage.4 > > > WANTLIB += Xau Xdmcp xcb-shm > > > *** Error 1 in target 'port-lib-depends-check' (ignored) fixed thanks to sysclean; it was due to some outdated crap I still had left around in this machine. retested everything, still works. attaching a fixed tarball. love.tar.gz Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
On Mon, Feb 13, 2023 at 11:17:05AM +0100, Omar Polo wrote: > On 2023/02/12 15:26:01 -0500, Thomas Frohwein wrote: > > I built the ports the executables still contain the minor version > > (love-0.10.2 love-0.8.0 love-11.4), which isn't a problem for me at > > this point, but it sounds like you wanted that to be different. > > Ops, here's the fixed tarball. > > (long story short, after all this time i thought that only love-11.4 > had the minor in the executable name, so I fixed that, forgetting to > check the others.) > > > A few WANTLIB seem to be missing for love 0.8: > > > > $ make port-lib-depends-check > > > > love-0.8.0p14(games/love/0.8): > > Missing: Xau.10 (/usr/local/bin/love-0.8.0) (system lib) > > Missing: Xdmcp.11 (/usr/local/bin/love-0.8.0) (system lib) > > Missing: xcb-shm.1 (/usr/local/bin/love-0.8.0) (system lib) > > Extra: Xdamage.4 > > WANTLIB += Xau Xdmcp xcb-shm > > *** Error 1 in target 'port-lib-depends-check' (ignored) > > this is strange! Here port-lib-depends-check is happy, and in > particular i can see -lXdamage in logs. > > can you please share the build log? it'd be interesting to see why > this happens. configure.in is not particularly complicated. build log at https://thfr.info/tmp/buildlog-love-0.8.txt; still with the above output after completing `make fake` and then `make port-lib-depends-check`. > > maybe we have different version of one lib depends that pulls in > different stuff? >
Re: games/love: bring in multiple versions
On 2023/02/12 15:26:01 -0500, Thomas Frohwein wrote: > I built the ports the executables still contain the minor version > (love-0.10.2 love-0.8.0 love-11.4), which isn't a problem for me at > this point, but it sounds like you wanted that to be different. Ops, here's the fixed tarball. (long story short, after all this time i thought that only love-11.4 had the minor in the executable name, so I fixed that, forgetting to check the others.) > A few WANTLIB seem to be missing for love 0.8: > > $ make port-lib-depends-check > > love-0.8.0p14(games/love/0.8): > Missing: Xau.10 (/usr/local/bin/love-0.8.0) (system lib) > Missing: Xdmcp.11 (/usr/local/bin/love-0.8.0) (system lib) > Missing: xcb-shm.1 (/usr/local/bin/love-0.8.0) (system lib) > Extra: Xdamage.4 > WANTLIB += Xau Xdmcp xcb-shm > *** Error 1 in target 'port-lib-depends-check' (ignored) this is strange! Here port-lib-depends-check is happy, and in particular i can see -lXdamage in logs. can you please share the build log? it'd be interesting to see why this happens. configure.in is not particularly complicated. maybe we have different version of one lib depends that pulls in different stuff? love.tar.gz Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
On Thu, Feb 09, 2023 at 10:56:15AM +0100, Omar Polo wrote: > On 2023/01/08 15:11:02 +0100, Omar Polo wrote: > > On 2023/01/07 13:56:26 -0500, Thomas Frohwein > > wrote: > > > On Thu, Dec 29, 2022 at 11:45:23AM +0100, Omar Polo wrote: > > > [...] > > > > > > Just took a look at this - there is an extra PLIST file at > > > games/love/11/PLIST that is different from games/love/11/pkg/PLIST. > > > > Oops, no idea how that ended up there. shouldn't have been present. > > > > > I would probably at comment `# C++11` above the COMPILERS line in the > > > Makefile.inc. > > > > not sure, 0.8 is not (maybe?) C++11. and since love depends on other > > C++ libraries it can't be built with base-gcc on gcc arches anyway > > (that's my understanding at least, there ports-gcc is used to build > > C++ libs.) > > > > thfr and namtsui found that at least Blue Revolver actually needs > > luajit instead of lua. I'm attaching an updated tarball that builds > > the engine with luajit if available. (The only exception is love-0.8 > > that explicitly wants lua-5.1.) > > ping :) > > re-attaching the port, i've only tweaked slightly love/11 so that the > executable is called love-11 and not love-11.4. before 11.0, upstream > used a versioning scheme of 0.X.Y with X being breaking changes and Y > not, now they've changed to X.Y. So love-11.4 doesn't make sense for > an executable, just like love-0.10.2 is similarly wrong. love-11 and > love-0.10 make more sense. (the package name has the full version of > course.) I built the ports the executables still contain the minor version (love-0.10.2 love-0.8.0 love-11.4), which isn't a problem for me at this point, but it sounds like you wanted that to be different. A few WANTLIB seem to be missing for love 0.8: $ make port-lib-depends-check love-0.8.0p14(games/love/0.8): Missing: Xau.10 (/usr/local/bin/love-0.8.0) (system lib) Missing: Xdmcp.11 (/usr/local/bin/love-0.8.0) (system lib) Missing: xcb-shm.1 (/usr/local/bin/love-0.8.0) (system lib) Extra: Xdamage.4 WANTLIB += Xau Xdmcp xcb-shm *** Error 1 in target 'port-lib-depends-check' (ignored) > > attaching a tarball because i'm completely changing the structure of > the port. > > ok to import? > I see no other issues, only the above. From my side this is ok thfr@ as long as WANTLIB is addressed; I'll leave the binary naming to you...
Re: games/love: bring in multiple versions
On 2023/01/08 15:11:02 +0100, Omar Polo wrote: > On 2023/01/07 13:56:26 -0500, Thomas Frohwein wrote: > > On Thu, Dec 29, 2022 at 11:45:23AM +0100, Omar Polo wrote: > > [...] > > > > Just took a look at this - there is an extra PLIST file at > > games/love/11/PLIST that is different from games/love/11/pkg/PLIST. > > Oops, no idea how that ended up there. shouldn't have been present. > > > I would probably at comment `# C++11` above the COMPILERS line in the > > Makefile.inc. > > not sure, 0.8 is not (maybe?) C++11. and since love depends on other > C++ libraries it can't be built with base-gcc on gcc arches anyway > (that's my understanding at least, there ports-gcc is used to build > C++ libs.) > > thfr and namtsui found that at least Blue Revolver actually needs > luajit instead of lua. I'm attaching an updated tarball that builds > the engine with luajit if available. (The only exception is love-0.8 > that explicitly wants lua-5.1.) ping :) re-attaching the port, i've only tweaked slightly love/11 so that the executable is called love-11 and not love-11.4. before 11.0, upstream used a versioning scheme of 0.X.Y with X being breaking changes and Y not, now they've changed to X.Y. So love-11.4 doesn't make sense for an executable, just like love-0.10.2 is similarly wrong. love-11 and love-0.10 make more sense. (the package name has the full version of course.) attaching a tarball because i'm completely changing the structure of the port. ok to import? love.tar.gz Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
On 2023/01/07 13:56:26 -0500, Thomas Frohwein wrote: > On Thu, Dec 29, 2022 at 11:45:23AM +0100, Omar Polo wrote: > [...] > > Just took a look at this - there is an extra PLIST file at > games/love/11/PLIST that is different from games/love/11/pkg/PLIST. Oops, no idea how that ended up there. shouldn't have been present. > I would probably at comment `# C++11` above the COMPILERS line in the > Makefile.inc. not sure, 0.8 is not (maybe?) C++11. and since love depends on other C++ libraries it can't be built with base-gcc on gcc arches anyway (that's my understanding at least, there ports-gcc is used to build C++ libs.) thfr and namtsui found that at least Blue Revolver actually needs luajit instead of lua. I'm attaching an updated tarball that builds the engine with luajit if available. (The only exception is love-0.8 that explicitly wants lua-5.1.) love.tar.gz Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
On Thu, Dec 29, 2022 at 11:45:23AM +0100, Omar Polo wrote: [...] Just took a look at this - there is an extra PLIST file at games/love/11/PLIST that is different from games/love/11/pkg/PLIST. I would probably at comment `# C++11` above the COMPILERS line in the Makefile.inc. Will try to test the different versions, but this came up immediately.
Re: games/love: bring in multiple versions
On 2022/12/29 11:31:42 +0100, Omar Polo wrote:
> On 2022/12/29 02:38:17 -0700, "Anthony J. Bentley" wrote:
> > Nice to see this.
> >
> > Omar Polo writes:
> > > The idea then is to move the current port for the 0.8.0 (assuming we
> > > want to keep it) as games/love/0.8.0 and add some other versions too,
> > > for the time being 0.10.4 and 11.4 (the latest.) 11.1 doesn't compile
> > > out of the box, and we can always add other versions later.
> >
> > My understanding is that LOVE keeps API compatibility between minor
> > versions, so 11.1 is obviated by 11.2 and eventually 11.4.
>
> I thought it was the case (that's why i haven't spent much energy in
> trying to port 11.1) but wasn't sure, thanks for confirming.
>
> it's also probably why they switched from 0.10.X to 11.Y at some
> point.
>
> > If that's
> > the case, we should rename the packaged files and the port directories
> > to 0.8, 0.10, and 11, and only package the latest of each.
>
> done
>
> > I would also like the version numbers in PLIST to use a SUFFIX variable
> > (as autoconf, etc. do).
>
> I avoided it initially because it leads to entries such as
>
> @lib lib/liblove-${VERSION}.so.${LIBlove-${VERSION}_VERSION}
>
> but maybe it's not bad.
I can't read, sorry. Here's a tarball that defines SUFFIX as autoconf
does. it still has entries like
@lib lib/liblove${SUFFIX}.so.${LIBlove${SUFFIX}_VERSION}
i've also only used SUFFIX in plists and Makefile.inc, not in the
other makefiles. should I change them xtoo?
> I've also lowered the autoconf and automake version to what upstream
> used (latest autoconf would warning about deprecated macros) and
> adjusted Makefile.inc not to add the lang/lua category (already done
> by lua.port.mk)
love.tar.gz
Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
On 2022/12/29 02:38:17 -0700, "Anthony J. Bentley" wrote:
> Nice to see this.
>
> Omar Polo writes:
> > The idea then is to move the current port for the 0.8.0 (assuming we
> > want to keep it) as games/love/0.8.0 and add some other versions too,
> > for the time being 0.10.4 and 11.4 (the latest.) 11.1 doesn't compile
> > out of the box, and we can always add other versions later.
>
> My understanding is that LOVE keeps API compatibility between minor
> versions, so 11.1 is obviated by 11.2 and eventually 11.4.
I thought it was the case (that's why i haven't spent much energy in
trying to port 11.1) but wasn't sure, thanks for confirming.
it's also probably why they switched from 0.10.X to 11.Y at some
point.
> If that's
> the case, we should rename the packaged files and the port directories
> to 0.8, 0.10, and 11, and only package the latest of each.
done
> I would also like the version numbers in PLIST to use a SUFFIX variable
> (as autoconf, etc. do).
I avoided it initially because it leads to entries such as
@lib lib/liblove-${VERSION}.so.${LIBlove-${VERSION}_VERSION}
but maybe it's not bad.
I've also lowered the autoconf and automake version to what upstream
used (latest autoconf would warning about deprecated macros) and
adjusted Makefile.inc not to add the lang/lua category (already done
by lua.port.mk)
love.tar.gz
Description: GNU Zip compressed data
Re: games/love: bring in multiple versions
Nice to see this. Omar Polo writes: > The idea then is to move the current port for the 0.8.0 (assuming we > want to keep it) as games/love/0.8.0 and add some other versions too, > for the time being 0.10.4 and 11.4 (the latest.) 11.1 doesn't compile > out of the box, and we can always add other versions later. My understanding is that LOVE keeps API compatibility between minor versions, so 11.1 is obviated by 11.2 and eventually 11.4. If that's the case, we should rename the packaged files and the port directories to 0.8, 0.10, and 11, and only package the latest of each. I would also like the version numbers in PLIST to use a SUFFIX variable (as autoconf, etc. do).
Re: games/love: bring in multiple versions
Le Mon, Dec 26, 2022 at 07:40:09PM +0100, Omar Polo a écrit : > forgot to mention another thing: I'm building all the versions of love > with lua 5.1. I don't know if all the games are fine with lua 5.1 or > if some titles wants a newer version. Building flavored versions of > each love version is not difficult (except maybe for the ugliness of > the binaries, we'd end up with stuff like love-11.4-5.3 :/) but I > prefer we figure out if it's needed or not. (and current tarball only > uses 5.1) > > When testing a title and being in doubt, building a version of love > targetting another lua version is easy: > > $ make clean='package plist' > $ make MODLUA_VERSION=5.4 clean repackage reinstall > > further testing is welcome :) I havent looked at the details of the port itself, just noted one thing when building 11.4: Warning: @option no-default-conflict without @conflict the cool thing is that 11.4 allows me to run https://laurentm74.itch.io/remake-fruity-franck-2020 : havent found all the keys yet, space resets level, c/v does left right, m does up, according to the lua code * should fire and / should do down but those dont work on my us kbd.. while the previous version of love badly failed on it: failed: Error: main.lua:6: attempt to call field 'setDefaultFilter' (a nil value) stack traceback: main.lua:6: in main chunk [C]: in function 'require' [string "boot.lua"]:331: in function <[string "boot.lua"]:227> [C]: in function 'xpcall' so an improvement :)
Re: games/love: bring in multiple versions
forgot to mention another thing: I'm building all the versions of love with lua 5.1. I don't know if all the games are fine with lua 5.1 or if some titles wants a newer version. Building flavored versions of each love version is not difficult (except maybe for the ugliness of the binaries, we'd end up with stuff like love-11.4-5.3 :/) but I prefer we figure out if it's needed or not. (and current tarball only uses 5.1) When testing a title and being in doubt, building a version of love targetting another lua version is easy: $ make clean='package plist' $ make MODLUA_VERSION=5.4 clean repackage reinstall further testing is welcome :) On 2022/12/24 13:40:20 +0100, Omar Polo wrote: > Here's another attempt at updating games/love, this time by using > multiple versions, thfr@ and bentley@ reminded me that's needed to run > more games (retrocompatibility is not really a thing.) > > The idea then is to move the current port for the 0.8.0 (assuming we > want to keep it) as games/love/0.8.0 and add some other versions too, > for the time being 0.10.4 and 11.4 (the latest.) 11.1 doesn't compile > out of the box, and we can always add other versions later. > > There's some tweaking around to allow multiple versions to be > installed at the same time: > > - love/0.8.0 only ship the bin/love executable. it gains a @pkgpath >for the updates (that I've tested successfully with pkg_add -u) and >it's renamed bin/love-0.8.0. i've also bumped the revision and >regenerated the wantlibs, otherwise it's basically the current >packaged version. > > % cd /usr/ports/packages/amd64/all > % ls > love-0.10.2.tgz love-11.4.tgz > love-0.8.0p14.tgz love-mime-0.1.tgz > % doas env TRUSTED_PKG_PATH=./ pkg_add -u love > love-0.8.0p13->0.8.0p14: ok > > - love/0.10.4 and 11.4 install a shared library and I had to patch >the Makefile.am to convince libtool to generate shared libraries >that the ports tree may like. They also install a symlink, a >static library and the .la file that I'm removing in a post-install >hook. Playing with --disable-static didn't help. > > - love/0.10.4 and 11.4 (and versions in between) also ship the MIME >type thingy for the desktops. I've moved this to a subpackage >love-mime and added it as RDEP on the affected versions to avoid >conflicts. love-mime just ship an icon and the xml for the mime >type applications/x-love-game definition. > > There's no file conflict between the currently packaged love-0.8.0 and > the new set of love ports, hence only the @pkgpath for the update and > no @conflict. I've added @option is-branch and @option > no-default-conflict that, per pkg_create(1), seems to be needed in > this case, but I'm still getting an error making the packages: > > % make package > [...] > Creating package love-0.10.2 > Warning: @option no-default-conflict without @conflict > > Anyway, all the versions are installable at the same time and seems to > work: > > % pkg_info | grep love > love-0.10.2 2D games framework for use with Lua > love-0.8.0p14 2D games framework for use with Lua > love-11.4 2D games framework for use with Lua > love-mime-0.1 MIME definition for applications/x-love-game > > > Since I'm changing the structure of games/love quite a bit, I'm just > attaching a tarball instead of generating a diff, hope it's fine. > > OK/comments welcome!
Re: games/love: bring in multiple versions
On 2022/12/24 13:40:20 +0100, Omar Polo wrote: > love-mime-0.1 MIME definition for applications/x-love-game Ops, fixed the typo (applications -> application) locally
games/love: bring in multiple versions
Here's another attempt at updating games/love, this time by using multiple versions, thfr@ and bentley@ reminded me that's needed to run more games (retrocompatibility is not really a thing.) The idea then is to move the current port for the 0.8.0 (assuming we want to keep it) as games/love/0.8.0 and add some other versions too, for the time being 0.10.4 and 11.4 (the latest.) 11.1 doesn't compile out of the box, and we can always add other versions later. There's some tweaking around to allow multiple versions to be installed at the same time: - love/0.8.0 only ship the bin/love executable. it gains a @pkgpath for the updates (that I've tested successfully with pkg_add -u) and it's renamed bin/love-0.8.0. i've also bumped the revision and regenerated the wantlibs, otherwise it's basically the current packaged version. % cd /usr/ports/packages/amd64/all % ls love-0.10.2.tgz love-11.4.tgz love-0.8.0p14.tgz love-mime-0.1.tgz % doas env TRUSTED_PKG_PATH=./ pkg_add -u love love-0.8.0p13->0.8.0p14: ok - love/0.10.4 and 11.4 install a shared library and I had to patch the Makefile.am to convince libtool to generate shared libraries that the ports tree may like. They also install a symlink, a static library and the .la file that I'm removing in a post-install hook. Playing with --disable-static didn't help. - love/0.10.4 and 11.4 (and versions in between) also ship the MIME type thingy for the desktops. I've moved this to a subpackage love-mime and added it as RDEP on the affected versions to avoid conflicts. love-mime just ship an icon and the xml for the mime type applications/x-love-game definition. There's no file conflict between the currently packaged love-0.8.0 and the new set of love ports, hence only the @pkgpath for the update and no @conflict. I've added @option is-branch and @option no-default-conflict that, per pkg_create(1), seems to be needed in this case, but I'm still getting an error making the packages: % make package [...] Creating package love-0.10.2 Warning: @option no-default-conflict without @conflict Anyway, all the versions are installable at the same time and seems to work: % pkg_info | grep love love-0.10.2 2D games framework for use with Lua love-0.8.0p14 2D games framework for use with Lua love-11.4 2D games framework for use with Lua love-mime-0.1 MIME definition for applications/x-love-game Since I'm changing the structure of games/love quite a bit, I'm just attaching a tarball instead of generating a diff, hope it's fine. OK/comments welcome! love.tar.gz Description: GNU Zip compressed data
