How to build JSFML

[pengcheng]

After installing WinSDK7.1 with VC++ 2010 compiler selected, and rebuilding "win32" ant target, the "Standalone" sample works!

One issue:
In my registry there's no "HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VS" "ProductDir".
Instead, there's "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VC" "ProductDir"=C:\Program Files\Microsoft Visual Studio 10.0\VC\.

So I use:
<target name="my_win32" description="Build the C++ sources for Windows 32 bit.">
      
      <property name="path.vs" value="C:/Program Files/Microsoft Visual Studio 10.0" />
      <property name="path.winsdk" value="C:/Program Files/Microsoft SDKs/Windows/v7.1" />
      
      <property name="cl" value="${path.vs}/VC/bin/cl.exe" />
      ...


One question:
Does the end user need to install VC++ 2010 runtime (to get msvcr100.dll & msvcp100.dll under C:\Windows\System32)? What'll be the supporting Windows environments of JSFML?

[pdinklag]

Good to know it works!

In my registry there's no "HKLM\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VS" "ProductDir".
Instead, there's "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Setup\VC" "ProductDir"=C:\Program Files\Microsoft Visual Studio 10.0\VC\.

Thanks, I will update the batch later so that gets detected.

Does the end user need to install VC++ 2010 runtime?

Yep, they will have to install it. A lot of Windows games need it these days, so it should not be much of a problem.

I should probably add an info line about the dependencies in the readme.
On Windows, you will need the VC++ 2010 runtime, on Linux, you need some packages (I know of libglew1.6 and libjpeg8 right now). No idea about Mac OS X. But this should be in the readme.

[Hiura]

No idea about Mac OS X

To use JSFML on Mac you only need jsfml.jar. That should be all. 

[pdinklag]

Like Ubuntu (and its spawns Linux Mint etc) then, great!

[Groogy]

Thought should try this binding out and give Java another chance though I can't create a basic application because you are trying to use libGLEW-1.6 while I only have libGLEW-1.8

Sitting on Arch Linux and I don't feel comfortable with this system yet to start pasting around stuff like glew libraries ^^

[pdinklag]

I hate Linux environments for these kinds of things...
Thanks for informing! I have yet to try and set up an Arch Linux VM. I suppose installing libGLEW-1.6 parallely isn't allowed by pacman?

[Groogy]

Well I think it would be allowed but there only seems to be version 1.8 in the repo =/
Thing with Arch is that everything is bleeding edge so i guess they remove packages as they become "obsolete"

[pdinklag]

OK, so is this similar to the problem with libjpeg / libjpeg-turbo I had on Fedora (the repo only has libjpeg-turbo).

Can you use / compile SFML, ie will it automatically link against libglew-1.8?

[Groogy]

Yepp it will

[pdinklag]

Hm, is there any way in Linux to link a library against two different versions of another library?

Unless the API changed or functionality of the later version is used, I understand that won't be possible, but in a case like this I wouldn't see a lot of trouble with it technically. Does SFML linked against libglew-1.8 work with libglew-1.6 ?

[Groogy]

Don't think so, but why do you have to link specifically to a version? You should be able to just link against libglew and have the already in place system for this handle it for you.

Don't know how experienced you are with Linux but we have something called a symbolic link. And you always keep a symbolic link to the latest version of the library without the version numbers.

Well it's simplified but it is something like:
libsomelibrary.so.1.9.1
libsomelibrary.so.1.9
libsomelibrary.so.1
libsomelibrary.so

So you can have several versions installed at the same time. The symbolic link is only used at compile time and the resulting binary remembers exactly what version it was compiled with.

[Laurent]

The symbolic link is only used at compile time and the resulting binary remembers exactly what version it was compiled with.

To be more precise, the resulting binary remembers the SO version it was compiled with, which is supposed to be the same for binary compatible versions of the library. The SO version can be the major version number, or major and minor version numbers, depending on the versioning conventions of the library.

The problem with some libraries is that they break binary compatibility with each new version, so other users must have the exact same version your project was compiled with.

[pdinklag]

Maybe I should go for a different approach after all and make the Linux version depend on the SFML 2 package and treat it as an external dependency. That's probably how it should be done anyway.

In that case, can I consider the current SFML2 library file names final so it will work once SFML2 appears in public repositories? What can be done for the "transition phase" - I don't really think SFML2 will be in any repos until a few months after the release...

For Windows, I would still prefer to contain the supported SFML binaries in the release, however, maybe I should place them at a relative location in the file system instead of packing them up. For Mac, since the linking process seems to require a bunch of tricks, I believe the same can be said, Hiura will know for sure though.

[Laurent]

Maybe I should go for a different approach after all and make the Linux version depend on the SFML 2 package and treat it as an external dependency. That's probably how it should be done anyway.

Absolutely!

In that case, can I consider the current SFML2 library file names final so it will work once SFML2 appears in public repositories?

Yep.

What can be done for the "transition phase" - I don't really think SFML2 will be in any repos until a few months after the release...

Add a link to the SFML download page?

[Hiura]

For Mac, since the linking process seems to require a bunch of tricks, I believe the same can be said, Hiura will know for sure though.

Yeah, I also think it's the easiest way to go.