SFML community forums
General => General discussions => Topic started by: christoph on June 22, 2008, 01:44:57 pm
-
Hi
It's me complaining again ;)
I have noticed you kept the soname for SFML in your 1.3 release while it clearly is API and ABI incompatible[1]. Could you please increase the soname at least for your 1.4 release?
I also have some changes (e.g. linking the sfml library files against each other as needed so they can ba loaded at runtime and one does not have to add an -lsfml-system when only using sfml-window) would you like me to have them applied to latest svn and providing an diff here? If wanted I would also setup an autotools build system for linux/unix systems.
[1] http://wiki.linuxquestions.org/wiki/Library-related_Commands_and_Files
-
I have noticed you kept the soname for SFML in your 1.3 release while it clearly is API and ABI incompatible[1]. Could you please increase the soname at least for your 1.4 release?
Yes, you're right. I'll try to fix this for the next release.
I also have some changes (e.g. linking the sfml library files against each other as needed so they can ba loaded at runtime and one does not have to add an -lsfml-system when only using sfml-window) would you like me to have them applied to latest svn and providing an diff here?
I'm not sure this would really be useful. I prefer keeping it consistent with static libraries and other platforms.
If wanted I would also setup an autotools build system for linux/unix systems
Would it really be better compared to the current makefiles ? I'm personally not an expert with this kind of Unix stuff, so giving me something I won't be able to maintain is not a very good idea ;)
-
An autotools setup would have some advantages:
- You can optimize the library for some specific architecture by adding an -march to the CXXFLAGS
- It supports stagged installs (http://www.gnu.org/prep/standards/html_node/DESTDIR.html#DESTDIR)
- You can have the user decide if he wants to use your builtin Versions for some libraries or link against the extra ones already installed (this is a security consideration. If e.g. zlib has an security flaw one would need to correct zlib directly and look for all packages using theír built in version of zlib and fix them too so it is unacceptable for inclusio in most distributions)
- You can easily cross compile SFML building on some arch and using on another
- the configure script can detect a lot of things automatically (e.g. endianess) without needing to guess based on arches
This is what I can currently imagine and I'm not an expert in autotools
Of couse the current makefiles do work (but it would really help to have options for stagged installation and installing things to /usr in stead of /usr/local is at best considered bad practise if it is not done through the package system of the distribution so there should be an $INSTALLDIR variable pointing to /usr/local by default and beeing changeable via INSTALLDIR=/opt (e.g.) make)
-
Ok, I see. Thanks for the details.
But as I said, I wouldn't be able to maintain it.
-
yeah.. make roxx ;) please keep make..
-
Hey, I suggest the creation of a tool [used to generate an autotool config file [used to generate makefiles [used to generate gcc calls]]] ...
Oops, that was obviously ironic :>
Voting for make here too.
It's simpler (and widely known) for "the rest of us", those only willing to quickly build on linux without additionnal needs other than make.
-
I've updated the makefiles so that both sonames and binaries names now use 1.x instead of just 1 as version number.
-
Great :)