Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: packageable things  (Read 2495 times)

0 Members and 1 Guest are viewing this topic.

tooky

  • Newbie
  • *
  • Posts: 1
    • View Profile
packageable things
« on: November 29, 2012, 03:42:16 pm »
Hello,

As far as I know there's nothing in the linux distro I use that's using SFML yet.

So I was wondering if there are games, small-games, or even toy-games yet around that are packageable?

Same question for libraries? I know the friend libraries are not stable yet, but are there some advanced enough to be considered packageable?

And then the last question but not least. We currently provide SFML 1.6.
So the options are:
- stick with 1.6 only
- provide both 1.6 and a more recent version
- remove 1.6 (nothing seems to use it so I think we can do), and provide only a more recent version

If we provide 2 versions next to each other, it would be fine to rename SFML 2.0 libs with the major verison number like -lsfml2-system etc. libsfml-system.so.2.0 can live next to libsfml-system.so.1.6 but what about the libsfml-system.so lymlink, it has to choose which to point to. If I've understood correctly, SDL 2.0 will include the 2 in the basename of the link for this issue.
But there are a lot of things using SDL 1.X, while I don't see much using SFML 1.6. So maybe just removing 1.6 is just the easiest solution.

If we provide a more recent version: SFML 2.0 RC1, or GIT?
Seems like the RC1 is quite old, and it seems there are no SFML 2.0 RC2 around or planed.

The release freeze is soon (not the same soon than this soon, because the date is known), so I've one remaining week to potentially help prepare things.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: packageable things
« Reply #1 on: November 29, 2012, 04:20:08 pm »
Quote
If we provide 2 versions next to each other, it would be fine to rename SFML 2.0 libs with the major verison number like -lsfml2-system etc. libsfml-system.so.2.0 can live next to libsfml-system.so.1.6 but what about the libsfml-system.so lymlink, it has to choose which to point to.
It thought this was the whole point of the symlinks: with them the user can choose which version to use by default (usually the latest one), but can also link to a specific version by linking to libsfml-xxx.so.2 or even libsfml-xxx.so.2.0 explicitely. I think a lot of libraries do it this way (ie. no major version number in the name).

Quote
If we provide a more recent version: SFML 2.0 RC1, or GIT?
The Git version is of course better, but it depends what you want: the best/most recent version, or the version that people are likely to use?

Quote
The release freeze is soon
The release of what? What are we talking about in this topic?
Laurent Gomila - SFML developer

gyscos

  • Jr. Member
  • **
  • Posts: 69
    • View Profile
Re: packageable things
« Reply #2 on: November 29, 2012, 04:42:05 pm »
Also, it's not because no other package depends on sfml that no one uses the sfml package.
Here, I use it to get the source and use it in my own projects - although the package actually fetches the latest git version, and not an outdated 1.6...