Created attachment 906859 [details, diff] patch file The following attached in a patch for an "improved" ebuild for games-engines/openmw-9999 based off of input from some devs working the OpenMW project. There's not too many changes compared to openscenegraph-openmw-9999.ebuild I have (which I will post a little later), but the main thing to note is 1. There is not really much of a point in OpenMW with a non-LuaJIT Lua version. While is _possible_ to do, the development of OpenMW will always (erm at least for now) use LuaJIT for the scripting capabilities. This simplifies some things with the ebuild. 2. Updated mode template version A more recent commit fixes a few things. 3. openscenegraph-openmw doesn't need to be built with zlib This was something I was told by the devs. I imagine there's a few things to tidy up, but with the ebuild (and the openscenegraph-openmw-9999 I will post) I can build OpenMW's master branch without issue with gcc and clang.
Small feedback incoming. Seems like you can build with Qt6? Gentoo is in the process of moving to Qt6. https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists.txt?ref_type=heads#L256 looking at https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists.txt?ref_type=heads#L52 and https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 > -DBUILD_LAUNCHER=$(usex qt5) > -DBUILD_OPENCS=$(usex devtools $(usex qt5)) > -DBUILD_WIZARD=$(usex qt5) I am not sure building the wizard is useful. So I would move the launcher behind $(usex launcher) $(usex launcher $(usex gui)). Move BUILD_OPENCS behind $(usex devtools $(usex gui)). Make gui default to Qt6. If there is any reason to keep Qt5 support add a default-off qt5 flag.
(In reply to Paul Zander from comment #1) > Small feedback incoming. > > Seems like you can build with Qt6? Gentoo is in the process of moving to Qt6. > > https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists. > txt?ref_type=heads#L256 > > looking at > https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists. > txt?ref_type=heads#L52 > and > https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 > > > > -DBUILD_LAUNCHER=$(usex qt5) > > -DBUILD_OPENCS=$(usex devtools $(usex qt5)) > > -DBUILD_WIZARD=$(usex qt5) > I am not sure building the wizard is useful. So I would move the launcher > behind $(usex launcher) $(usex launcher $(usex gui)). Move BUILD_OPENCS > behind $(usex devtools $(usex gui)). > > Make gui default to Qt6. If there is any reason to keep Qt5 support add a > default-off qt5 flag. I think at the time when I first made this was when not all of the Qt5 packages necessary to build OpenMW were available. I'll double check and see if that's changed (probably has).
(In reply to Alec Stewart from comment #2) > (In reply to Paul Zander from comment #1) > > Small feedback incoming. > > > > Seems like you can build with Qt6? Gentoo is in the process of moving to Qt6. > > > > https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists. > > txt?ref_type=heads#L256 > > > > looking at > > https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists. > > txt?ref_type=heads#L52 > > and > > https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 > > > > > > > -DBUILD_LAUNCHER=$(usex qt5) > > > -DBUILD_OPENCS=$(usex devtools $(usex qt5)) > > > -DBUILD_WIZARD=$(usex qt5) > > I am not sure building the wizard is useful. So I would move the launcher > > behind $(usex launcher) $(usex launcher $(usex gui)). Move BUILD_OPENCS > > behind $(usex devtools $(usex gui)). > > > > Make gui default to Qt6. If there is any reason to keep Qt5 support add a > > default-off qt5 flag. > > I think at the time when I first made this was when not all of the Qt5 > packages necessary to build OpenMW were available. I'll double check and see > if that's changed (probably has). Sorry, *Qt6 packages.
https://wiki.gentoo.org/wiki/Project:Qt/Qt6_migration_notes is going to be helpful
Why did you remove the keywords? > There is not really much of a point in OpenMW with a non-LuaJIT Lua version. 2 reasons: 1. S3ctor in that your conversation said "You can use regular Lua", and since you *can*, I just gave the choice to the user. 2. Arch support. E.g. dev-lang/lua and games-engines/openmw are keyworded on ~ppc64, but dev-lang/luajit is not. Yes, there are people who play OpenMW on ppc64 :) Why did you add IUSE=lua? Is it possible to build it without lua support? > Seems like you can build with Qt6? Some features are missing in that build: https://gitlab.com/OpenMW/openmw/-/issues/6491#note_1274825059 Re openscenegraph-openmw ebuild: it's mostly just a copy of openscenegraph ebuild, with very little changes. And because the two OSGs can't be installed together, I don't want to remove features from it which are not used by OpenMW itself - someone can require dev-games/openscenegraph for some other app, but still want to enjoy improved performance in OpenMW. For this case it's possible to use the fork for other apps, via packages.provided. Another reason is if the 2 ebuilds are similar, it's easier to copy changes from one to another. So please don't change the ebuild too much, unless you also want the same changes to the openscenegraph ebuild. > I am not sure building the wizard is useful It's hard to start the game without importing certain files from Morrowind installation. Either way, wizard's only dependency is Qt itself, so I'd be against putting it behind its own USE flag.
Created attachment 906909 [details, diff] opemw-9999 with Qt6 patch
Huzzah! OpenMW builds fine with Qt6 and the launcher works fine. I'll try to move some other stuff around to not compile with the launcher and wizard as options.
(In reply to Alexey from comment #5) > > There is not really much of a point in OpenMW with a non-LuaJIT Lua version. > > 2 reasons: > > 1. S3ctor in that your conversation said "You can use regular Lua", and > since you *can*, I just gave the choice to the user. Sure, that's understandable. >2. Arch support. E.g. dev-lang/lua and games-engines/openmw are keyworded on >~ppc64, but dev-lang/luajit is not. Yes, there are people who play OpenMW on ppc64 :) Ah, okay that's more important than the first to me. > Why did you add IUSE=lua? Is it possible to build it without lua support? I'm not 100% sure, but I assume it's possible. It's kind of one of those things of "you can do it, but I don't know why you would". But I guess it shouldn't be removed. > > Seems like you can build with Qt6? > > Some features are missing in that build: > https://gitlab.com/OpenMW/openmw/-/issues/6491#note_1274825059 > > Re openscenegraph-openmw ebuild: it's mostly just a copy of openscenegraph > ebuild, with very little changes. And because the two OSGs can't be > installed together, I don't want to remove features from it which are not > used by OpenMW itself - someone can require dev-games/openscenegraph for > some other app, but still want to enjoy improved performance in OpenMW. For > this case it's possible to use the fork for other apps, via > packages.provided. Another reason is if the 2 ebuilds are similar, it's > easier to copy changes from one to another. So please don't change the > ebuild too much, unless you also want the same changes to the openscenegraph > ebuild. Ah okay. Makes sense. So keep zlib then *and* the patches? > > I am not sure building the wizard is useful > > It's hard to start the game without importing certain files from Morrowind > installation. Either way, wizard's only dependency is Qt itself, so I'd be > against putting it behind its own USE flag. That was my thought, but if we're saying that we can allow users to build OpenMW with a non-JIT Lua, even if they aren't on ppc64, I don't know if restricting building without with wizard and launcher should be out of the question.
(In reply to Alexey from comment #5) > > Seems like you can build with Qt6? > > Some features are missing in that build: > https://gitlab.com/OpenMW/openmw/-/issues/6491#note_1274825059 > That issue is closed. Is that still an issue? > > I am not sure building the wizard is useful > > It's hard to start the game without importing certain files from Morrowind > installation. Either way, wizard's only dependency is Qt itself, so I'd be > against putting it behind its own USE flag. Yeah. That's a very good reason to keep. @Alec: No qt6 use-flag, make it gui per https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 If you should add a qt5 fallback, add a qt5 flag.
(In reply to Paul Zander from comment #9) > > > I am not sure building the wizard is useful > > > > It's hard to start the game without importing certain files from Morrowind > > installation. Either way, wizard's only dependency is Qt itself, so I'd be > > against putting it behind its own USE flag. > > Yeah. That's a very good reason to keep. Sure, but it is _possible_ as noted in the comment: > USE flag 'qt5' is disabled, 'openmw-launcher' and > 'openmw-wizard' are not available. You are on your own for > making the Morrowind data files available and pointing > openmw at them.\n\n So it's really what seems to be best to y'all, I'm still pretty new to all of this. The new gui flag could be enabled by default, and it's up to the user to disable it if they really want. > @Alec: > > No qt6 use-flag, make it gui per > https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 > > If you should add a qt5 fallback, add a qt5 flag. Got it.
> That was my thought, but if we're saying that we can allow users to build OpenMW with a non-JIT Lua, even if they aren't on ppc64, I don't know if restricting building without with wizard and launcher should be out of the question. I don't understand this sentence, sorry. After the initial import is done, wizard is no longer useful. Launcher is used to change some settings like list of mods enabled, which is possible to do by editing configs manually. Neither of these 2 tools got any dependencies except Qt, so I don't see a reason to add a USE flags for enabling these tools specifically. What's your proposal, and what it has to do with Lua on ppc64?
Do this: > -DBUILD_LAUNCHER=$(usex gui) > -DBUILD_OPENCS=$(usex devtools $(usex gui)) > -DBUILD_WIZARD=$(usex gui)
Yeah, that works. Basically, just rename existing "qt5" to "gui"
> Ah okay. Makes sense. So keep zlib then *and* the patches? Inside osg-openmw ebuild, yes. The usedep string in openmw ebuild - if [zlib] part is not actually used by openmw, can be removed from openmw ebuild
(In reply to Alexey from comment #11) > > That was my thought, but if we're saying that we can allow users to build OpenMW with a non-JIT Lua, even if they aren't on ppc64, I don't know if restricting building without with wizard and launcher should be out of the question. > > I don't understand this sentence, sorry. > > After the initial import is done, wizard is no longer useful. Launcher is > used to change some settings like list of mods enabled, which is possible to > do by editing configs manually. Neither of these 2 tools got any > dependencies except Qt, so I don't see a reason to add a USE flags for > enabling these tools specifically. > Sorry, I didn't explain it well. So say we're on amd64. If the user can either compile OpenMW with Lua 5.[1-4] or LuaJIT, why is it out the the question to let the user keep or disable the GUI tools? > What's your proposal, and what it has to do with Lua on ppc64? Nothing with Lua on ppc64, that obviously can't change. It's simply about allowing the user to disable the GUI tools, should they desire. So by default, the gui USE flags would be +gui, and it'd be up to the user to go to their package.use to do -gui.
The question was about allowing to disable launcher / wizard outside of USE=gui. Which is not useful. So don't do it. Do https://bugs.gentoo.org/942291#c12
> why is it out the the question to let the user keep or disable the GUI tools? The user can keep or disable it via USE=qt5 (currently) or via USE=gui (after the rename). We shouldn't take this choice away, enforcing the dependency on qt. > So by default, the gui USE flags would be +gui, and it'd be up to the user to go to their package.use to do -gui. Looks reasonable, yes.
Created attachment 906910 [details, diff] openmw with option to not build gui tools Okay, I think I'm getting closer. Again, apologies for any silly mistakes or poor explanations.
Created attachment 906911 [details, diff] openmw-9999 optional gui and needs openscenegraph with same lua Realized we probably want OpensceneGraph (omw fork or not) to be built with the same version of Lua as OpenMW.
I've just tested the Qt6 build, and CS seems to work now. Though for some reason it was picking up Qt5 until I patched the find_package() line to remove Qt5 from there.
Created attachment 906913 [details] cleanup version - you can not do -qt5, qt5 has the same meaning - sorted IUSE - sorted RDEPEND - cleaned up gui? duplicate - fixed lua deps. you need to depend dev-games/openscenegraph[lua] if you have lua, and there is no reason to force your LUA_SINGLE_USEDEP onto it if you don't use lua - removed duplicate ${LUA_DEPS} - fixed qt lookup
`MY_TEMPLATE_COMMIT="master"` won't work. It may download it once, but then use that copy forever. Moreover, in case if you don't have it downloaded yet, the Manifest will complain when a commit happens there, because hash changed. If you really want, the template would need to be plumbed via git-r3 eclass. But IMHO specifying a single commit and updating the number from time to time is good enough, considering that the 9999 ebuild needs to change itself from time to time. Something happened with indentation of qt5 deps there. Why is qt5 useful for this anyway since switch to qt6? Btw, you forgot dev-qt/qtsvg:6 and dev-qt/qttools:6[linguist]
> openmw *can* be built without lua, however this is a "why would you" situation. Looking at https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists.txt?ref_type=heads#L474-481 - the word REQUIRED makes me suspicious. How exactly it works without lua? Can you share the build log?
I stand corrected - wizard has an additional dependency. https://gitlab.com/OpenMW/openmw/-/blob/master/CMakeLists.txt?ref_type=heads#L425-426 What I mean, you shouldn't put app-arch/unshield inside qt5 branch.
(In reply to Alexey from comment #22) > Something happened with indentation of qt5 deps there. Why is qt5 useful for > this anyway since switch to qt6? If qt5 is no longer needed, then we can get rid of it. > Btw, you forgot dev-qt/qtsvg:6 and > dev-qt/qttools:6[linguist] Ah, that's right. I'll need to change the openscenegraph-openmw-9999 ebuild I have because I get: [ebuild R ~] dev-games/openscenegraph-openmw-9999:0/162::local-repo USE="collada gif gstreamer jpeg lua png sdl sdl2 svg truetype zlib -curl -debug -dicom -doc -egl -examples -fltk -fox -gdal -las -openexr -openinventor -osgapps -pdf -tiff -vnc -wxwidgets -xrandr" LUA_SINGLE_TARGET="lua5-1%* -lua5-3% -lua5-4% -luajit*" 0 KiB [ebuild R *] games-engines/openmw-improved-9999::local-repo USE="gui%* lua osg-fork -devtools -doc -qt5% -test (-qt6%*)" LUA_SINGLE_TARGET="lua5-1%* -lua5-3% -lua5-4% -luajit*" 0 KiB So it doesn't try to build with luajit even when I have something in my package.env to make sure luajit is used.
Created attachment 906916 [details, diff] with the extra Qt dependencies
I don't know what you changed in osg-openmw ebuild, but openscenegraph-openmw-3.6_p20221115-r1.ebuild only supports lua5-1, just like dev-games/openscenegraph-3.6.5-r114 Was it selecting luajit before the usedep change? It currently uses luajit for me > Realized we probably want OpensceneGraph (omw fork or not) to be built with the same version of Lua as OpenMW. Can you explain why? OSG's lua is not used by OpenMW.
Created attachment 906917 [details] cleanup version v2 - adds fetching the test file via git - drops USE=lua - drops USE=qt5
An issue I found when building with the cleaned version: CMake Error at CMakeLists.txt:254 (find_package): find_package for module Qt5 called with REQUIRED, but CMAKE_DISABLE_FIND_PACKAGE_Qt5 is enabled. A REQUIRED package cannot be disabled. CMake Error at components/CMakeLists.txt:561 (QT_WRAP_UI): QT_WRAP_UI called with incorrect number of arguments -- Found SQLite3: /usr/include (found version "3.46.1") CMake Error at apps/launcher/CMakeLists.txt:59 (QT_ADD_RESOURCES): Unknown CMake command "QT_ADD_RESOURCES". That first one is odd, being that Qt5 is marked REQUIRED but even the project is moving to Qt6. I'll post the build.log I have.
Created attachment 907016 [details] build.log with Cmake error regarding QT_WRAP_UI Here's that build.log file.
Here's the line in the CMakeLists.txt on GitLab: https://gitlab.com/OpenMW/openmw/-/blob/master/components/CMakeLists.txt#L561 Here's a couple related lines: https://gitlab.com/OpenMW/openmw/-/blob/master/components/CMakeLists.txt#L523 https://gitlab.com/OpenMW/openmw/-/blob/master/components/CMakeLists.txt#L621
Created attachment 907082 [details] cleanup version v3 Try this. The cmake code first tries to find either Qt5 or Qt6. Which breaks with CMAKE_DISABLE_FIND_PACKAGE_Qt5, because it it declares Qt5 as required. That code is really suboptimal.
(In reply to Paul Zander from comment #32) > Created attachment 907082 [details] > cleanup version v3 > > Try this. > > The cmake code first tries to find either Qt5 or Qt6. Which breaks with > CMAKE_DISABLE_FIND_PACKAGE_Qt5, because it it declares Qt5 as required. That > code is really suboptimal. That ebuild works.
If you just change github.com with gitlab.com in the SRC_URI it won't work, it shows error 403 with the 0.48 release with that URL. The correct URL would look like https://gitlab.com/OpenMW/openmw/-/archive/openmw-0.48.0/openmw-openmw-0.48.0.tar.bz2 But main reason it's using github instead of gitlab there is because https://openmw.org/downloads/ points at github. I'll just revert this change if you don't mind. I'll also copy KEYWORDS from the 0.48.0 (still hidden behind else), not limiting it to just amd64. Dropping only x86 from it because devs did say that x86 doesn't have enough RAM to play even the base game. Moved dev-qt/qttools:6 to BDEPEND, because it's only executed during build, not linked to etc. Added another missing dep sys-libs/zlib. `rm -rf || die` is redundant: -f hides errors Why ln instead of just copy the test file to the right place from the start? `sed -e 's/player/Player/g' -i apps/openmw_tests/mwworld/testptr.cpp || die` why? If it's a bug in the test, fix it upstream? ---- I'll test it again today, and upload updated ebuild
(In reply to Alexey from comment #34) > If you just change github.com with gitlab.com in the SRC_URI it won't work, > it shows error 403 with the 0.48 release with that URL. The correct URL > would look like > https://gitlab.com/OpenMW/openmw/-/archive/openmw-0.48.0/openmw-openmw-0.48. > 0.tar.bz2 > > But main reason it's using github instead of gitlab there is because > https://openmw.org/downloads/ points at github. I'll just revert this change > if you don't mind. I was told by the devs that Gitlab was supposed to be the upstream, not Github. That's probably something they've forgotten to change on the website. :P > I'll also copy KEYWORDS from the 0.48.0 (still hidden behind else), not > limiting it to just amd64. Dropping only x86 from it because devs did say > that x86 doesn't have enough RAM to play even the base game. > > Moved dev-qt/qttools:6 to BDEPEND, because it's only executed during build, > not linked to etc. Makes sense. > `rm -rf || die` is redundant: -f hides errors > > Why ln instead of just copy the test file to the right place from the start? > > `sed -e 's/player/Player/g' -i apps/openmw_tests/mwworld/testptr.cpp || die` > why? If it's a bug in the test, fix it upstream? That's not a question for me, I didn't add that.
(In reply to Alexey from comment #34) > `rm -rf || die` is redundant: -f hides errors Drop the -f? > Why ln instead of just copy the test file to the right place from the start? Because for -9999 it's copied out of the git checkout. And the rest of the checkout is removed after. > `sed -e 's/player/Player/g' -i apps/openmw_tests/mwworld/testptr.cpp || die` > why? If it's a bug in the test, fix it upstream? I didn't want to split out the patch to make the build work. Yes, sending a patch upstream is the right thing to do.
This git-r3_fetch didn't put the correct file there, but a small text file with a reference to Git LFS. In fact, this file was not used by test at all in the latest git version, because they moved some directories around. Now it's supposed to be in components_tests/data/ instead. And... changing the version of the template doesn't work, because it's hardcoded in cmake to that specific version: https://gitlab.com/OpenMW/openmw/-/blob/master/apps/components_tests/CMakeLists.txt#L114-118 If the file's hash doesn't match, src_configure tries to download the file anew, and fails due to the sandbox. I'll revert this change as well.
The PR is at https://github.com/gentoo/gentoo/pull/39146, now just need to wait for a dev to look at it and merge Thanks for contribution!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b56388833c6fae1dc67abe789f891ca9ba248bc6 commit b56388833c6fae1dc67abe789f891ca9ba248bc6 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2024-10-28 21:52:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-11-29 00:11:54 +0000 games-engines/openmw: update live * Use Qt 6 * Update USE flag from qt5 to gui * Update directory layout to match upstream * Copy KEYWORDS from release, but drop x86: devs say that it doesn't have enough RAM to even play the vanilla game Closes: https://bugs.gentoo.org/942291 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Co-authored-by: Alec Stewart <alec-stewart@protonmail.com> Co-authored-by: Paul Zander <negril.nx+gentoo@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/39146 Signed-off-by: Sam James <sam@gentoo.org> games-engines/openmw/openmw-9999.ebuild | 70 +++++++++++++++++++++------------ 1 file changed, 45 insertions(+), 25 deletions(-)
