Created attachment 248938 [details] devel/sfml: Update to 2.6.1 Update to 2.6.1: - Makefile maintenance - Drop local patch https://www.sfml-dev.org/changelog.php#sfml-2.6.1
poudriere-testport: > 13.2-{amd64,i386}-release: OK > 14.0-{amd64,i386}-release: OK > main-{amd64,i386}: OK
Created attachment 249062 [details] Update to 2.6.1 Complete integration of examples. Update commit log. poudriere-testport: > 13.2-{amd64,i386}-release: OK > 14.0-{amd64,i386}-release: OK > main-{amd64,i386}: OK
poudriere-testport main-amd64: > games/slade : OK > games/marblemarcher : OK > graphics/lux : OK > games/etracer : OK games/emptyepsilon fails, and is somewhat behind upstream, which has since moved to SDL-2.
Created attachment 249104 [details] Update to 2.6.1 Fix ${FIND}-fu ${_EXAMPLES_ASSETS} poudriere-testport: > 13.2-{amd64,i386}-release: OK > 14.0-{amd64,i386}-release: OK > main-{amd64,i386}: OK
Note that you can't just update it as it would break consumers ports and I thus do not approve this change for merging. We would probably need to add it as another port.
(In reply to Dmitry Marakasov from comment #6) Hi Dmitry, What consumers are you worried about? How have you concluded that I have apparently "just updated" the Port, completely ignoring the consumers of it?
(In reply to Dmitry Marakasov from comment #6) > We would probably need to add it as another port. I believe you are suggesting moving the update in this PR, to a new, separate Port? I would be guessing here, but devel/sfml26? If this is correct, I do not understand why, and would appreciate some clarity, and insight. The logic appears inverted here, why make a separate Port when only 1 out 7 consumers fail? I propose, we create a new Port of the current SFML version 2.5.1. My reasoning for this is, only one consumer of SFML in Ports, games/emptyepsilon, fails to build with SFML-2.6.1, the remaining 6[1] consumers build fine, and we can keep devel/sfml tracking upstream releases. Would love some direction, with reason. 1: https://www.freshports.org/devel/sfml
This does not really matter, but yes preserving current port as sfml25 and updating sfml to 2.6 is also fine. Have you checked whether emptyepsilon can be fixed with 2.6?
(In reply to Dmitry Marakasov from comment #9) > Have you checked whether emptyepsilon can be fixed with 2.6? I investigated updating games/emptyepsilon, found that the project moved to SDL[1], and requires a new external engine, Serious Proton[2], which is an SDL2 stack. I did not investigate patching the current Empty Epsilon to work with an updated SFML. I am thinking, if I have time, I might create a new Port for Serious Proton, which would facilitate updating Empty Epsilon, and nullifying it's dependency on SFML. This way, all Ports suffering on devel/sfml, will be updated. 1: https://github.com/daid/EmptyEpsilon/wiki/Build-%E2%80%90-Linux-%E2%80%90-Debian 2: https://github.com/daid/SeriousProton