This seemed like a perfectly acceptable plan, one which would leave me next week to finish off the GLSL chapter examples and do some serious work on my college stuff (I'm aiming for 1:1 across the board, I like to aim high [wink]).
So, I finish up the docs quickly enuff, using the same format as the OGLWFW docs, and begin work on the examples, where apon I hit my first problem.
Due to how the library is linked even if you dont use the PhysFS stuff it still needs to link to the PhysFS library.
So, 3 more projects later and the GTL now builds with and without PhysFS support and the simple non-PhysFS example compiles just fine.
Now, I moved onto the PhysFS example and this is where problem two appears. You see, both GTL and PhysFS require the zlib123 library to be compiled in, so both statically compile it in. However at link time this comes with a slight issue, as whatever library is included 2nd complains about a redefintion of certain functions in certain object files.
So, back to the projects which use PhysFS and I tell VS not to compile the zlib123 files, instead figuring that the end user will be using PhysFS with zlib compiled in so we can just let the linker sort that out.
Nope, no dice, instead now the GTL libs complain about 3 functions not being present at link time.
At this point yesterday I screamed and went out to get drunk, the end to a perfectly crappy 2 days *sigh*
So, I'm trying to figure out how to get around this, I could just ensure a copy of the functions got compiled in by moving them to their own cpp/obj file, that would probably get around the problem, however if people want to change the version of zlib used by libpng later this then becomes an issue as its not a simple case of adding the new files to the project.
The alternative would be not to compile zlib in at all and tell the end user to link to the zlib module in all cases. However as PhysFS statically compiles in zlib this would still land you in multiple defined function land..
Library dev. can be such a damned pain at times...