Dependencies: Let’s have just one more

A few days back, I evaluated some libraries to be used in a C++ based application. At first glance, one of these looked particularly good. Lots of well written and detailed documentation, a nice to use API and quite some success stories. I decided to give it a try, which was exactly when I encountered a first minor inconvenience. While the library was available as pre-built release for a vast amount of operating systems, 32 bit as well as 64 bit, there was no official, pre-built release for the required 64 bit Windows. Thus, I had to compile it myself. No problem so far.

For this case, the documentation even had a section listing the dependencies required for building the library. Due to this list being not very long, I was rather enthusiastic to finally be able to try the library.

To cut it short, that list was all but complete.

I spent the better part of the afternoon trying to get the build done. All in vain. When I resolved one dependency, another until then unknown dependency arose, then the next, and so on. When I reached the point where a dependency required Fortran to be built (no joke!) I eventually decided to abandon the nice looking library in favor of another one, which isn’t nearly as all-embracing and nice, but at least won’t take me even deeper into dependency hell.

This rather frustrating experience made me wonder, whether the authors of the library even once tried to build it on another than the development machine? And if so, why didn’t they bother to include a complete list of the dependencies into the documentation?

2 thoughts on “Dependencies: Let’s have just one more”

  1. You are doing it wrong. We have package managers for that now. Not on Windows of course, so it may not be your fault.

    Or, if all libraries had listed their own dependencies in a Maven pom you could have let Maven figure it all out. Of course they either haven’t (Java libaries) or couldn’t (non-Java components). Again: not your fault.

    Why should the author of a library list the dependencies of his dependencies? Thats the jobs of the authors of the libraries he depends on. (Apply DRY and all of the other same principles you use when writing Java code.)

    Also, would you prefer if the library just reinvented some wheels instead of using those provided by other libraries?

    But I think the real problem is that we have no single package management system that just works and is used everywhere (Windows/AllLinuxDistros/…, Java/AllOtherLanguages). Instead we have this mess of a few hundred special-purpose package managers.

    (And while we are at it: auto-update “features” in programs are another symptom of this problem.)

    But of course one could be so much more pragmatic and blame it on the library.

    1. Of course, I do neither want the author of a library to reinvent the wheel, nor do I want him to list all dependencies of his dependencies. But at least he could provide a complete list of his own dependencies. Yet, such a list was not present in this example. Supposedly (clearly speculative) because the author was unaware of some of them, or perhaps considered them to be installed on each and every machine on this planet. Installing/building the library on a clean machine would have exposed missing dependencies.
      Using Maven etc. also only works if you list all of your own dependencies, so why should one do otherwise when not using Maven?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.