warzone2100 hard depends on OpenSSL. Should have LibreSSL support
Unconvinced that OpenSSL should even be a dep anymore: https://github.com/Warzone2100/warzone2100/commit/f1c474153f7c55b5b39a9fdb805a7a7a4c1819c8, actually
(In reply to Sam James from comment #1) > Unconvinced that OpenSSL should even be a dep anymore: > https://github.com/Warzone2100/warzone2100/commit/ > f1c474153f7c55b5b39a9fdb805a7a7a4c1819c8, actually Looks like a version bump and removal of the dep is all that should be needed then. I have tried to build 3.4 myself but I haven't quite figured out the new build system just yet.
(In reply to 0xC0ncord from comment #2) > (In reply to Sam James from comment #1) > > Unconvinced that OpenSSL should even be a dep anymore: > > https://github.com/Warzone2100/warzone2100/commit/ > > f1c474153f7c55b5b39a9fdb805a7a7a4c1819c8, actually > > Looks like a version bump and removal of the dep is all that should be > needed then. I have tried to build 3.4 myself but I haven't quite figured > out the new build system just yet. Agreed. Looks like it's cmake now, so a good place to start is rip out anything autotools and inherit the cmake eclass. This bump is on my list, but PRs are welcome too of course. :)
Created attachment 659889 [details] warzone2100-3.4.1.ebuild: WIP This is the ebuild I was using. It builds and installs, but the executables fail to run due to rpath and other errors.
Finally got around to finishing up the ebuild. This one fully installs and runs. There's probably still some work to be done here though, as I've not yet tested the debug USE flag, nor am I certain if it's still relevant. Additionally, there may be some things I have written in the ebuild that can be done differently.
Created attachment 680572 [details] warzone2100-3.4.1.ebuild
Created attachment 680575 [details] metadata.xml
(In reply to 0xC0ncord from comment #5) > Finally got around to finishing up the ebuild. This one fully installs and > runs. There's probably still some work to be done here though, as I've not > yet tested the debug USE flag, nor am I certain if it's still relevant. > Additionally, there may be some things I have written in the ebuild that can > be done differently. Thank you. I really appreciate it - I started looking at this and hit some strange CMake issues. Few notes: * It's easier for me to review via GitHub but if you prefer Bugzilla, that's fine with me. * Can you provide a git am-able patch? (use git format-patch) * Can you include the GCO sign off with your real name in a comment? Ebuild feedback (none of it's a big deal, I can do it if needed) * Use the cmake elass instead of cmake-utils.eclass (deprecated) * One blank line after EAPI * -DBUILD_SHARED_LIBS="OFF" looks interesting. What're the shared libraries in Warzone even for? * We can drop the xdg_* calls and the phases referencing them (if they're just that) if we use xdg.eclass instead of xdg-utils.class
(In reply to Sam James from comment #8) > (In reply to 0xC0ncord from comment #5) > * It's easier for me to review via GitHub but if you prefer Bugzilla, that's > fine with me. > > * Can you provide a git am-able patch? (use git format-patch) > > * Can you include the GCO sign off with your real name in a comment? > Sure. I will submit a PR with the changes. > Ebuild feedback (none of it's a big deal, I can do it if needed) > * Use the cmake elass instead of cmake-utils.eclass (deprecated) > > * One blank line after EAPI Alright. > * -DBUILD_SHARED_LIBS="OFF" looks interesting. What're the shared libraries > in Warzone even for? The final warzone2100 binary includes some additional library code (found in the 3rdparty directory) that's normally linked in statically. Gentoo's default behavior is to always build dynamically linked libraries, but statically linking these libraries is the current behavior for the current versions of Warzone in the tree. These libraries are: - libivis-opengl.so - libre2.so - libsdl-backend.so - libsequence.so - libsound.so - libwidget.so Of these, I know that libsdl-backend, libsequence, libsound, and libwidget are specific to Warzone 2100 and don't exist elsewhere. libre2 I know is in the Portage tree. libivis-opengl.so I have no clue. > * We can drop the xdg_* calls and the phases referencing them (if they're > just that) if we use xdg.eclass instead of xdg-utils.class Got it.
PR opened at https://github.com/gentoo/gentoo/pull/18912
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d5b17b3563fd6e4750372c25f8d2fefb5b5eabab commit d5b17b3563fd6e4750372c25f8d2fefb5b5eabab Author: Kenton Groombridge <me@concord.sh> AuthorDate: 2021-01-02 17:12:38 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-01-14 14:13:49 +0000 games-strategy/warzone2100: version bump to 3.4.1 Version 3.4.0 also introduces a new cmake build system, which required reworking of the ebuild. Bug: https://bugs.gentoo.org/741984 Signed-off-by: Kenton Groombridge <me@concord.sh> Closes: https://github.com/gentoo/gentoo/pull/18912 Signed-off-by: Sam James <sam@gentoo.org> games-strategy/warzone2100/Manifest | 1 + games-strategy/warzone2100/metadata.xml | 4 + .../warzone2100/warzone2100-3.4.1.ebuild | 124 +++++++++++++++++++++ 3 files changed, 129 insertions(+)
