Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

GTL : Biting the bullet

Sign in to follow this  


If you've been following things even remotely you'll know that my current GTL problems revolve around not being able to smoothly intergrate GTL and PhysFS into an exe due to zlib issues, namely both libs requiring it and compiling it in.

After much thinking in the bath last night I decided this was dumb.
I mean, not just 'opps, that was dumb' level of dumb but a 'wtf? OMFG!' level of dumb.

Allow me to explain;

I guess people like their libs to be self contained, as such they ship everything they need with the lib so people can get up and running.
OK, this is all good and fine but leads to a slight 'issue', one of which I've run into, when two libs want to use the same library and both try to compile it in, at which point the linker throws a wobbly, chucks an error message at you and sits in a corner in a huff.

So, whats the solution to this I hear you cry?
Its simple; give an option to build WITHOUT the libs included. Let the final linking steps muddle out the details, I mean thats why its there after all. You compile your library, it declares it looking for a few external functions and when you link everything together if they are there then everything works fine, if they arent then we are back into the linker wobbly zone anyways.

Note I said; optional.
For some people having a build which includes the libs is handy, they just want to get up and running, but when combing libs together it becomes a nightmare of biblical proportions.

As a classic example of it done "right" look at the boost iostreams library.
This library can work with a couple of compression schemes, however it expects you, the end programmer, to supply the libs and turn it on if you want it to work.

So, I propose the same thing.
Every library which depends on an external library should either supply an optional build system which doesnt include the external library into the build OR just supply the code you need and make it clear you need to supply the rest.

This infact should make things more flexible, as it will allow the end user to update their support libs (for bug fixes for example) and also to control their build enviroment properly.

So, with this in mind I'm going to overhall the GTL and change the PhysFS version so that it requires the final linking stage to fix everythig up.
I'm also going to add 'dll' versions of libs, as some people like to use dlls with their code. Ofcourse, as I use static objects in the code I've no idea how this is going to react right now, heh

Anyways, I urge you all to consider my words and if you agree then contact your lib providers and ask them to consider what I've said at least, I'm fully convinced it will help (and I'll be emailing the PhysFS guys on this as soon as I've something done towards it).

This might push back the release date slightly, but all things considered it should make things smoother in the long run.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!