5 replies to this topic

[Albertone]

I was wondering whether professional indie/shareware developers compile (and/or mantain/customize) every open source library they use or if they happen to release their products with the prebuilt binaries usually found on the homepage of the libraries.
In the past I used to write all the code to interface OpenGL etc to Win32, however my current pet project uses SDL. The prebuilt DLLs I downloaded work just fine, so I was wondering if directly including them in the end product folder wouldn't be a little, ahem, lame

[Reedbeta]

I think if the prebuilt stuff works fine for you then it's perfectly fine to keep it out of your build process.

Getting a third-party library integrated into your build process is usually a pain. However, it's often necessary because of annoying incompatibilities, such as you and the prebuilt binary disagreeing on which version of the CRT (C runtime library) you want to use, or whether you have STL iterator debugging turned on or off, etc. This is more of an issue using statically linked libraries than DLLs. And of course if you want to make any modifications then you have to build stuff from source. Finally, it can be useful to build from source just so that you get debugging information and can therefore step into the library code with the debugger if you need to. But if none of those conditions obtain, then using prebuilt binaries is fine.

[TheNut]

I personally never use pre-built libraries. I just don't trust them, what they linked to and whether or not they had viruses on their systems at the time of the build. Many open source projects are compiled by unofficial 3rd parties, especially for windows binaries. People that tend to use shady aliases rather than their real names doesn't help either. Also, many libraries come with extensions that may or may not be included by default. Zlib for instance has zip support if you compile it in. Some people find that useful.

If you statically link against everything (though you will run into DLL hell if dynamically link), you need to rebuild your libraries whenever you switch your CRT, as Reed noted above. This has been a fairly standard practice when upgrading visual studio over the years. Same goes for whenever I update my Linux box.

[Stainless]

I have no choice, I have to port any libraries I want to use anyway as I don't work on linux or windows

[Vilem Otte]

Basically on our game project we use code that is either created by us, open sourced and portable (without weird, huge, and too abstract dependencies like stl) - same goes for libc (better use something useful like glibc, not that M$ garbage), templated basic containers (tiny stl variant also), etc.

[Stainless]

From the code I have to port, the most common are....

1) STL
2) Boost
3) Magic particle system
4) libpng
5) libjpg
6) tinyxml
7) zlib
8) ziplib

Some games use others, but those are used by most games