Linking dependencies

[eXpl0it3r]

Now my concern is purely practical.  Sticking to Windows here (on Linux the precompiled binaries never worked for me anyway so I had to compile from source there), would the list of library names we have to tell Visual C++ to link against be a constant?  Or would we have to worry about different lists of libraries depending on what iteration of Windows we have?

It shouldn't change as long as SFML doesn't add/change dependencies.

P.S.: How do most C++ devs learn this stuff?  Every textbook/tutorial/class/guide I've seen/used for people new to C++ says NOTHING about pragmatic linking issues (they define conceptually linking but never mention what's involved in linking to other people's code).  So did you all have to learn this stuff through aimless googling and asking stupid questions on forums?

Well I'm not sure if there are "C++ books" that teach such things in depth, but there are official documents of compilers and alike in the internet. Yes they are hard to read, but they'll teach you about anything you would ever want to know or even more.
Personally I've learned a lot by experimenting and chatting with more experienced people on IRC, but even to this day I don't understand everything fully.
I'd say, I really learned A LOT about CMake, MinGW and compiling/linking by setting up FlexWorld on Windows. I sat about two full days on the PC figuring out what's going on in those CMake files and try to fix issues with MinGW and since FlexWorld depended on at lot of libraries it trained me the hard way how to link them. But a lot of important inputs came from Tank, so I doubt it's possible to learn everything just by trying, one needs some sort of source.

Also I've bookmarked this for a while, it contains some nice info, but doesn't go too much into detail.

[Tank]

Just wanted to say thank you for the change! And guys, I like old-school stuff very much, but: http://www.yworks.com/de/products_yed_about.html

[Ixrec]

That looks amazing O_O  I am never using PowerPoint for graphs again.  Would be nice if it could magically plug in to doxygen somehow.

Once the evil macro is banished I'll try compiling the latest sources to make extra sure it's still newbie-friendly, since I'm the closest thing to a newbie in this thread.

[Nexus]

This means in your project linker settings, you will need to specify opengl32 gdi32 winmm glew openal etc. But this is such wide-spread convention every C++ programmer is expected to know and understand how to do this already.

I don't remember doing this all the time, for a lot of libraries it's fine to link a single target (but maybe it's because I linked dynamically). Specifying all the low-level libraries is annoying even for non-beginners, because you have to memorize implementation details (that may even change over versions).

Don't forget that on Windows, it's not unusual to make use of automatic linking. Boost does this for example, and it might also be something to consider for SFML.

So did you all have to learn this stuff through aimless googling and asking stupid questions on forums?

MSDN is a good source for Windows-related development. I also learned a lot with Thor and its CMake configuration. But CMake itself was quite a pain to learn, because I hardly found clean, bigger examples...

[binary1248]

I don't remember doing this all the time, for a lot of libraries it's fine to link a single target (but maybe it's because I linked dynamically). Specifying all the low-level libraries is annoying even for non-beginners, because you have to memorize implementation details (that may even change over versions).

On Windows, for development of Windows applications that open up a window and do stuff interacting with the operating system, it doesn't matter what library you use, you will always need to link against winmm user32 gdi32 etc. So it isn't really a matter of memorizing implementation details (because it is always present regardless of library used), it's because the Windows executable loader doesn't do it for you automatically. On Linux and I guess OS X you need to do the same, randr X11 etc. So it's really just boilerplate, and has nothing specific to do with SFML. If you specify more than you need, the linker will just discard the superfluous stuff. But really... boilerplate project settings is something that I don't want to start complaining about It is an O(1) operation after all. A simple solution to this would be to provide templates for the popular IDEs that SFML already has support for in its tutorials. It would be a welcome addition .

Don't forget that on Windows, it's not unusual to make use of automatic linking. Boost does this for example, and it might also be something to consider for SFML.

Correct me if I'm wrong, but this automatic linking you refer to, wouldn't be that #pragma lib directive we've all seen would it? If so, this isn't portable since it isn't supported by GCC. See the note here. Don't know if clang breaks tradition and has support for it or not.

[Nexus]

Correct me if I'm wrong, but this automatic linking you refer to, wouldn't be that #pragma lib directive we've all seen would it? If so, this isn't portable since it isn't supported by GCC.

Ok, then at least provide it for Visual Studio users. The g++ guys should finally introduce something like that, too

On Windows, which libraries would one now have to link explicitly that weren't necessary before?

[eXpl0it3r]

I don't remember doing this all the time, for a lot of libraries it's fine to link a single target (but maybe it's because I linked dynamically). Specifying all the low-level libraries is annoying even for non-beginners, because you have to memorize implementation details (that may even change over versions).

As said before you still can do things as always with dynamic linking. Only static linking is affected by these changes.
It only seems bad because many Windows libraries make it too easy. It's totally normal to link against all the dependencies and no you don't need to know implementation details, you only need to know its dependencies. We Windows user are a bit spoiled anyways, because we don't need to install any dependencies at all, they are either integrate into Windows or get ship with SFML as precompiled libraries.

If it's too much asked for some people, then they might want to stick with shared libraries.

Don't forget that on Windows, it's not unusual to make use of automatic linking. Boost does this for example, and it might also be something to consider for SFML.

What do you mean with "automatic linking"?

[binary1248]

https://github.com/SFML/SFML/blob/master/src/SFML/System/CMakeLists.txt
https://github.com/SFML/SFML/blob/master/src/SFML/Network/CMakeLists.txt
https://github.com/SFML/SFML/blob/master/src/SFML/Window/CMakeLists.txt
https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/CMakeLists.txt
https://github.com/SFML/SFML/blob/master/src/SFML/Audio/CMakeLists.txt

All the libraries passed as EXTERNAL_LIBS to sfml_add_library. All of those in system, window and network are Windows specific (winmm, user32, gdi32, ws2_32) and will always be provided with any compiler/SDK bundle. The others specific to graphics and audio are openal32, glew32 (although sometimes this one is often provided as well), sndfile, jpeg and freetype. Laurent will need to set CMake up so they are copied to the SFML library install directory next to the SFML library files so the linker will be able to find them as well when linking them into projects.

[FRex]

What do you mean with "automatic linking"?

#pragma comment(lib,"somelibyouwannadd.lib") probably, headers that have this pragma and add libs to libs list. Boost does that on visual so you don't have to type something that looks like boost_fs_vs10_hello_man_what_up_1_53_lib_static.lib all the time.

[binary1248]

Oh, and I just discovered that Visual Studio goes ahead and links against all the common Windows libraries already by default:

Code: [Select]

kernel32.lib
user32.lib
gdi32.lib
winspool.lib
comdlg32.lib
advapi32.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
odbc32.lib
odbccp32.libThey are under "inherited values" so I guess they are part of the default configuration Visual Studio applies to all projects. Who thought a simple Hello World application could tax the linker this much?

[Laurent]

Done.

Now please do me a favor: answer to all those people that use the latest revision of SFML and will post here because of linker errors -- until the next release and its updated tutorials

[binary1248]

There are 2 kinds of people, no not 10, 2... those that know how to link, and those who don't know how to link. Take your pick which ones would have posted here anyway . We are prepared .

P.S. Maybe someone would be kind enough to update the FAQ? Laurent seems to hint at this becoming an FAQ (singular) .

[Nexus]

Do you plan to update FindSFML.cmake, such that the SFML_LIBRARIES variable also contains the dependencies? Or maybe create a new variable?

[Laurent]

Do you plan to update FindSFML.cmake, such that the SFML_LIBRARIES variable also contains the dependencies? Or maybe create a new variable?

It seems like a good idea.

[Nexus]

Tell me if I can help you somehow

It would only affect Windows, wouldn't it? Do you rather want to add everything to SFML_LIBRARIES or create a separate variable SFML_DEPENDENCIES? I'm thinking of scenarios where one of the dependencies is also linked besides SFML (as it was the case for GLEW in SFGUI); maybe it would be good to have separate variables for the "core" SFML libraries and the dependencies...

Also, these variables should probably include Windows libraries, e.g. winmm.lib?