Red Hat Bugzilla – Bug 979801
Provide an extra Package for SFML-2.0
Last modified: 2013-09-04 13:46:18 EDT
Description of problem:
Some programms need the "old" SFML-1.6 libraries. So make a new SFML-2.0 package instead of overwriting the existing one (an example is vbam-gtk).
Steps to Reproduce:
1. yum upgrade (to SFML-2.0)
2. yum install vbam-gtk (rawhide must be enabled)
3. see an error
*** Bug 979802 has been marked as a duplicate of this bug. ***
SFML-2.0 is parrallel-installable with 1.6 now. Hans was working on compat-SFML16. Hans, would you be able to provide an update on this?
(In reply to Julian Sikorski from comment #2)
> SFML-2.0 is parrallel-installable with 1.6 now. Hans was working on
> compat-SFML16. Hans, would you be able to provide an update on this?
Yes, long story short: I got side tracked with other stuff. But I've just picked up the track again and completed my compat-SFML16 package, see bug 983922 for the review request, please review.
Once compat-SFML16 has been reviewed I'll build it for rawhide and F-19, while also upgrading the F-19 SFML packages to SFML-2.0 (merging it with the fedpkg master branch). Then I'll push both SFML-2.0 and compat-SFML16 as F-19 updates in one update.
So if I can get a review of compat-SFML16 (easy, just a pkg rename of the existing F-19 package), we can have this resolved pretty quickly.
compat-SFML16-1.6-1.fc19,SFML-2.0-2.fc19 has been submitted as an update for Fedora 19.
Package compat-SFML16-1.6-1.fc19, SFML-2.0-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing compat-SFML16-1.6-1.fc19 SFML-2.0-2.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
compat-SFML16-1.6-1.fc19, SFML-2.0-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
I found a problem in the acutal FindSFML.cmake, if you have both installed.
When you do this:
find_package(SFML 2 COMPONENTS system REQUIRED)
it will throw out this:
SFML found but version too low (requested: 2, found: 1.x)
You will have a 50% chance of finding your correct version, otherwise it will break with an error.
The cmake file tries to find the SFML/Config.hpp, which does exist twice, one for the old 1.6 and a new one for 2.0. Depending on which file will be found first, you will have the correct version or not.
You could provide a switch for the version, but that will lead to a nasty workaround, but I don't see any other solution now.
Maybe you can make up your mind.
(In reply to Marcel Hellwig from comment #7)
> I found a problem in the acutal FindSFML.cmake, if you have both installed.
> When you do this:
> find_package(SFML 2 COMPONENTS system REQUIRED)
> it will throw out this:
> SFML found but version too low (requested: 2, found: 1.x)
Well then don't do that. SFML-2.0 comes with pc files as shipped upstream, and cmake is perfectly capable of using pkg-config, and when available that is preferred over find_package, exactly because find_package does this blind groping around until it found something which may or may not work.
I've no intention of supporting building against SFML for projects which don't use pkf-config, so please fix the buildfiles for whatever you're trying to build to use pkg-config.
> You will have a 50% chance of finding your correct version, otherwise it
> will break with an error.
> The cmake file tries to find the SFML/Config.hpp,
Yes, which is the wrong thing todo find_package is broken by design, so better not use it, esp. not when there is a sane alternative in the form of using pkg-config through pkg_search_module / pkg_search_modules, see /usr/share/cmake/Modules/FindPkgConfig.cmake .
> but I don't see any other solution now.
Use pkg-config is the solution.