How to handle engine dependencies

[3DModelerMan]

How do most game engines handle dependencies? I want the user of my engine o be able to just add the include directory, and the lib directory and link. But to link to it you have to link to all of it's dependencies as well. My engine depends on Irrlicht, and SPARK, and Bullet, and it will be depending on a lot more later. How do I make it so that you only have to link to the engine? I already moved the 3rd party headers to an "include/depend" directory. What should I do about the libs? Should 3rd party libs just go in the same lib directory as my engine libs? And I would provide project templates?

[REDDemon]

if you wrap the external library providing your own headers you just need to statically link the external library in your engine library. This way the user must use your own headers instead of the library headers. (just one of the possible ways). If you are using a dll you need to set "dllexport" under windows for stuff wich will be available to the user through the headers. (so if you give the user headers of external library user can still use it if linked properly with dllexport/import stuff setted up correctly).

[3DModelerMan]

So I have to edit the headers of all the dependencies? I'm using premake is there any way that it can link a library into another library? But I've tried adding all the libs to the engine library in premake and it didn't work, when I tried to link the engine into a test app it had a bunch of undefined symbols. What if I set it up so that including the engine's header files would link to everything using #pragma? That way linking would be automatic, and it would only pull in the dependencies it needs. Is there anything similar to #pragma linking in GCC and on other platforms?

[REDDemon]

nope. Most libraries provide a single macro for dll export. Let's take for example glew. you have to set "GLEW_STATIC" as precompiler define, else is assumed dynamic linking (dllimport, if you are compiling your dll with glew you have to set GLEW_BUILD wich creates the library using dllexport). good designed libraries will simplify your life. Bad designed libraries (or libraries wich are thinked for something else) will complicate your life.

That's why most users prefers a wrap around them. You have your own interfaces and coding style wich make them more easy to understand. And you can cut-off unwanted features by simply don't wrapping certain functions. With wrapping you are also no longer dependent on external library API because if implementation changes but your engine is using your API you have just to edit the Wrapper implementation but not your engine entire codebase. Wrapping a library requires good design skill and take of course a lot of extra time, but if done well can save a lot of time (but later). you are also warned that wrapping adds another layer of abstraction.