Jump to content
  • Advertisement
Sign in to follow this  
3DModelerMan

Managing dependencies when writing middleware

This topic is 1340 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've got a library that I've written that I think could be a useful middleware package that I'd like to try releasing on a small scale. It depends on a couple open source libraries though (they're zlib licensed though, so licensing isn't an issue right now). What I'm trying to decide though, is what the best way to distribute the middleware is with the dependencies. It's a static lib right now, and all the dependencies have to be manually linked to by specifying include and lib directories in the projects that use my library. What would be the best way to go about including dependencies in a framework/middleware library? How do most large middleware libraries manage their 3rd-party dependencies? Or do they just write everything in-house to avoid having to deal with it? For now I've just collected the .lib files of all the dependencies in one folder, and I've started to remove direct includes of 3rd-party library headers from my own header files. What would the next step be in making my library client friendly?

Share this post


Link to post
Share on other sites
Advertisement

Typically you provide the source.

 

That way when an organization needs to use your stuff, and they are already using some duplicate dependencies, they can reference their existing ones.  Or if their older dependencies are out of date or are customized, they can replace as appropriate.  It also allows the organization to ensure the build settings and the linking settings and other things you may not have thought about are all build with the right settings.

 

As a common example, the vast majority of games replace the standard memory management systems with their own solutions. The generic memory management provided in the standard runtimes is able to do many things, but fails pretty badly in situations like alignment concerns and allocation pools and quick teardown (although C++11 did a little bit with the last one). If your library is relying on the standard runtime for memory allocation it can cause issues with their framework. The developer will probably be contacting you, asking for the source so they can replace it and build with their custom allocators, likely with three or four different builds each with their own settings for tracking and other support..

Share this post


Link to post
Share on other sites

Okay, so what about for the default configuration then? Is it reasonable to just expect the client to link to all the library dependencies manually in every project that uses the library?

Share this post


Link to post
Share on other sites
Pretty much.

Another option is to bundle the source code for those dependencies if they're small. It's not uncommon for your typical game to have several copies of zlib linked in from different middleware DLLs based on which middleware they use and how much time the developer had to sort out the duplicates (just make it easy to turn off the bundled copy!).

I highly recommend having pre-built ready-to-use SDK packages with the headers and precompiled .DLL/.so/.framework stuff for popular platforms and compilers. A developer has a bazillion things to do and figuring out a build system just to _try_ your middleware is a good way to make sure they don't bother trying it at all (unless it's already a big famous package that they're reasonably sure they want).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!