SFML as a static library on Mac

[tanis]

Hello,

I'm obviously doing something wrong. I compiled SFML as static libraries for Mac OS X. In my project I am linking those libraries but then the linker is complaining that it can't resolve all of the symbols coming from the dependencies of SFML. I understand that they're not static libraries but frameworks. Why aren't they being included as static libraries as well?
And even then, how are you supposed to tell Cmake to link those frameworks as well?
I tried adding the usual -framework FLAC etc to target_link_libraries but it complains that it cannot find those frameworks. How do you tell where they are? (They're in the same folder as the SFML static libraries in my project btw)
Thanks in advance!

[Hiura]

You need to install frameworks to use them at runtime (or play with the rpath). That's one thing. In any case, to look into specific directories you need to tell your compiler so: similarly to `-I` and `-L` you have `-F` (RTFM for details).

But anyway, on OS X you rarely need static libraries. Application bundle can embed dynamic libraries such as frameworks so that in the end it's the same for the user. Actually, unless Apple changed its policy, it is even not encouraged to use static libraries on this OS.

So the question is: why do you want to statically link your app? A windows habit?

[tanis]

Thanks for the answer Hiura.

My question is part of a broader problem to be honest.
I thought I'd venture into statically linking the libraries to make it easier to get all of the different platforms to compile. As you pointed out, this is even worse than using frameworks on OS X.

Right now I'm writing a library that sits on top of SFML and I need it to work on OS X, Windows, Android and iOS.

On Mac I've been using frameworks but since I'm a cmake newbie, I'm having troubles finding a way to tell XCode to copy the frameworks into the application bundle.

On Windows I have a whole different problem, where I need to bring with me x86/Debug, x86/Release, x64/Debug, x64/Release multiplied by all the different versions of Visual Studio because of the incompatibility of the different STL versions.

On iOS I have to use static libraries because everything has to be linked statically.

It's a lot of different moving parts. And on top of that, the end user who's making a project using my library has to deal with all that stuff again as the linking is being done at that stage of course and not in my library. It makes it a dependency hell and it feels like it requires a lot of boilerplate just to get a simple test project to run.

Is my approach completely wrong? Is there a better way to deal with dependencies?

Cheers!

[Hiura]

Is my approach completely wrong? Is there a better way to deal with dependencies?

No, I think you're asking the right questions. 

On Mac I've been using frameworks but since I'm a cmake newbie, I'm having troubles finding a way to tell XCode to copy the frameworks into the application bundle.

You can use something similar to what I'm doing when you create a SFML template project in Xcode: a bash script is executed after the compilation phase to copy the deps inside the resulting application bundle. Here is the raw script.

On Windows I have a whole different problem, where I need to bring with me x86/Debug, x86/Release, x64/Debug, x64/Release multiplied by all the different versions of Visual Studio because of the incompatibility of the different STL versions.

Fortunately, debug vs release is not an issue on OS X. And if you want to target x86 & i386, you can create universal binaries. If you do so, be aware that we currently have a bug related to that with SFML: #1006

Since we use CMake for SFML, you can have a look at how the script works and get some inspiration from that.

[tanis]

Thanks for the script Hiura, that's definitely going to be useful.

I'm only going to support x64 on OS X. Most projects around the net seem to head in that direction and I feel safe going that way as well. I'm expecting people to play on relatively modern hardware.
I will probably do the same for Windows so that I can get rid of the x86 stuff as well.

I already took both SFML and Thor cmake scripts as a reference. Nonetheless I feel it very hard to make a rock solid cmake build script with all the differences of the different operating systems.

Do you think that it could be fine to include the libraries in SFML's extlibs folder as is and also add compiled libraries of SFML for the different platforms to my own library to make it easier for who's working on the actual executable to link everything without having to go through the configuration of all the dependencies involved?

[Hiura]

Do you think that it could be fine to include the libraries in SFML's extlibs folder as is and also add compiled libraries of SFML for the different platforms to my own library to make it easier for who's working on the actual executable to link everything without having to go through the configuration of all the dependencies involved?

That could be a solution, indeed. But keep in mind that doing that will imply more work for you as a maintainer: when SFML gets a patch, you'll have to pull all the change into your library's extlibs folder as well. It might be somewhat better to let people do that themselves (and actually learn that process with is *very* important).

Installing external libraries becomes even more and more easy on OS X with widespread use of brew, which is the equivalent of apt on Debian, unofficially at least. And to be honest, I'm inclining to change how things are done in SFML in the future to rely on such tools instead of maintaining extra stuff to focus more on SFML development itself because it might look simple in appearance but actually this is quite time and energy consuming.

I'm only going to support x64 on OS X. Most projects around the net seem to head in that direction and I feel safe going that way as well.

Yes, that's a safe bet IMO.