Package SFML as a self contained dependency

[adinapoli]

It would be extremely cool, in the same vein of packages like hipmunk, to ship the complete self contained SFML + CSFML with this bindings, allowing end user to not bother with external dependencies.
Do you think it would be feasible?

[jeannekamikaze]

Sure. I suppose the description in the .cabal file should be changed then.

[adinapoli]

Brill!
Happy new year btw. I have been working on a small game using SFML + netwire and I'm almost ready to showcase it under the form on a blog post to attract attention on our bindings :)

A.

[jeannekamikaze]

Wait, for some reason I misread your initial post. I thought you wanted to merge SFML and SFML-Control into one big package, which is why I said the description in the .cabal file should then be changed, so as to explain what's going on. As far as my understanding goes, shipping SFML + CSFML is not an option. The reason is that CSFML is not C, it's just unmangled C++, and cabal cannot deal with C++ files, at least the last time I checked.

[jeannekamikaze]

I suppose we could get around with some Setup.hs hacking, compiling SFML and CSFML and then the bindings themselves. However, that would still require the user to previously install cmake, since it is needed to build SFML. I suppose it's doable, but do you think it's worth the hassle?

[adinapoli]

Hi :)
As a bit of an unrelated note, I think we are doing the right thing in keeping SFML and SFML-control separated. I'm using the latter in a small game experiment, and the performance overhead might be such to discourage its adoption for "serious" real time applications.

As regards the topic itself I'm just looking forward to the adoption of these bindings. Every application willing to use Haskell and SFML for game dev would need sooner or later to package the game as a standalone app, via static linking, and I'm not sure that our current setup will allow it (but I'm ignorant on the topic).
Furthermore, releasing the bindings + the bound library will allow us to version freeze sfml and csfml to a version we trust and know is working against the bindings.
That will be my main rationale :)

[jeannekamikaze]

Well, I have been modifying the .cabal file and added a Setup.hs to compile SFML and CSFML. Since static linking with CSFML is a no-go, I am faced with two problems:

1. Cabal's 'extra-lib-dirs' does not work with relative paths because there's no path to set a path relative to. Cabal suggests using ${pkgroot}, but I have no idea how to do that and the user guide does not even mention that variable.
2. If I hard-code full paths in extra-lib-dirs as a temporary solution, the demos compile but they don't run unless $LD_LIBRARY_PATH is overriden or the hard-coded paths to the SFML and CSFML libraries are added to $PATH. This also means that loading any code on ghci will royally fail. HSSFML should work on ghci.

Let's see if I find a way to get around these problems.

[adinapoli]

I still have to wrap my head around these problem, but as soon as I do I'll try to help with the troubleshooting. I hear you though, dealing with this stuff is always tricky :)

[jeannekamikaze]

The problem is that, no matter what you do, the user will ultimately have to copy the shared libs / dlls somewhere in their PATH. I can't do this from the build script because I don't know where to copy to. Plus, even though cabal creates its own .cabal directory, a vanilla installation of cabal / haskell platform does not set up any paths other than those for ghc and mingw on windows, which in any case would require root to touch.

I have come up with a mixed solution that would offer several ways to build the library:

1. Simply run 'cabal install SFML' off of hackage. The build script assumes that SFML/CSFML have already been installed, and that the include paths are available. If the latter is not true, one can still use --extra-include-dirs as mentioned in the installation manual. To compile the demos, one simply has to cabal install and then run as usual.
2. If the user does not have SFML/CSFML installed, or their version does not match ours, they can use cabal to build it. The user runs cabal unpack, then cabal install, and manually copies the shared libs that the build script will make available to somewhere in their PATH. To install the demos, a cabal install and then running as usual is enough.
3. The user manually compiles SFML/CSFML and then installs HSSFML by following the installation manual that is already available.

What do you think ?

Edit: of course, if we do it this way all those steps would be documented in the installation manual.

[adinapoli]

Hi Marc.
What if we choose a way more pragmatic and easy approach, namely enforcing upper and lower bounds for SFML and CSFML inside the Setup.hs file? This way we can at least make sure our bindings will target the correct versions of SFML/CSFML, and gives us freedom to experiment with more sophisticated approaches, whilst having at least a naive mechanism to enforce versioning. What you reckon? I'm generally open to any solution :)

[jeannekamikaze]

Hmm, how exactly do I check the version of an existing SFML installation ?

[adinapoli]

that's a very good question. Some possibilities on top of my mind:

a) We ask on the SFML forum for hints (parse the headers perhaps?)
b) We write a small C/haskell program that tries to use certain functionality of the library, and if it fails we assume the version is not correct. I don't know though how far we can get with this.
c) We generate a checksum for the installed library we want to target and we compare the results. If they diverge (e.g. we can ship the haskell package with precomputed MD5 hashes , one per platform) we abort the installation. Not sure how reliable this can be.

[jeannekamikaze]

Success! I have managed to statically link with SFML and CSFML on Linux. I had to edit some include files because cmake was creating libraries with mangled names. All the demos are working flawlessly, and the user's .cabal file need not worry about anything because SFML's .cabal file does everything for you. The only problem now is that one has to run "cabal copy" to get SFML/CSFML static libs copied over to cabal's installation directory. If I can find a way to hook the build process to do this automatically, then it'll be pretty much done.

[adinapoli]

Great job! Can I help with the Mac OS X side of things?

[jeannekamikaze]

Yeah, I can do linux and windows. I still have to figure out how to avoid the copy hook. I'll push the changes when I get everything working under linux.

[adinapoli]

fantastic, really happy of the outcome :)