new s25rttr-9999 ebuild

[stefson]

The s25rttr live ebuild in the overlay is outdated and not compiling right now, it seems as if the s25rttr-cmake.patch needs some adjustments because of recent changes in the build system made by upstream. I tried to work it out, but do not have much of a clue how to solve this.

thank you

[nE0sIghT]

s25rttr build system became even more package-unfriendly

[stefson]

I agree upon that, even if I lack of a deeper understanding of cmake and its synthax it all seems to be optimized for their build server and the binaries they build automatically. Which links all libs statically into the binary, therefore bloating it, etc. pp.

you could solve the problem temporarily via EGIT_COMMIT="" , the last working one for me was 3b3bfdd4171270572949d0c3f9b179be7d5bbf24

[nE0sIghT]

Should be fixed now

[stefson]

Thank you for your effort, much appreciated. It compiles fine, but there are two or three little problems. First, if I do type s25client in a terminal it does not start the client, but gives this error

Executable not at '"/home/user/s25client"' Press ENTER to close this window . . .

the binaries are to be found in /usr/bin/ , my guess is that it should be rather in /usr/games/bin/ However, the game starts just fine if using the full path.

Also it would be great to somehow display the upstream git commit used to build the binaries, the binaries provided by upstream have the build date and the git commit in the title bar of the window.

And there is one minor problem when build with cmake-3.6, complaining about a missing policy during configure. Will discuss this with upstream, I guess.

[nE0sIghT]

First, if I do type s25client in a terminal it does not start the client, but gives this error

cd into /usr before running s25client. As I see upstream make more changes to bind binaries to some folder structure making it less portable. Or just run it from Applications menu of your DE.

the binaries are to be found in /usr/bin/ , my guess is that it should be rather in /usr/games/bin/

They are should not. games.eclass is deprecated and all binaries should be in /usr/bin by the decision of Gentoo's Council

[stefson]

Thanks for pointing out the depreciation of the games.eclass, wasn't aware of it.

I will discuss the missing cmake policy and the change in the folder structure with upstream, but could you please adapt your patchset a little, so that the build date and the git commit used to build the snapshot are displayed at the title bar of the window? Just like their binaries are doing! This is really helpfull for debugging during testing.

[nE0sIghT]

could you please adapt your patchset a little, so that the build date and the git commit used to build the snapshot are displayed at the title bar of the window

It's how upstream daily build are looks like?

[stefson]

It normally looks like this, date-build + commit id from git as you can see. Unfortunatly the build system changed so drastically that I'm not getting it anymore on my own where to alter your patch or the code base to bring it back.

[stefson]

For an unknown reason the cmake policy warning has disapeared, so with the build-id patch being merged all problems on our end are solved.

[nE0sIghT]

@stefson

I will look into it in couple of days. Thanks for PR