TSANCHEZ'S BLOG

So you're going to publish a Library

So you have a bunch of utility code laying around, and you think its worth putting out there for the world to see? Lots of people do it, and there are a lot of really commonly used libraries out there that you may already be using. But there is still a lot that can go wrong when you release code.

The first step should always be to check if your code even compiles. This may sound simple, but its an easy step to get wrong. Check in all your code. Make sure you have an easy way to see files that aren’t part of the repo yet (git status), and make sure everything is checked in that should be. Now, find a VM, new computer, chroot, or just wipe the local repository. Now, checkout the code to a different directory, and build. What are you likely to find? One, you’re linking to specific files in your origional directory structure. This is bad, as it makes it harder for someone else to compile the code. Two, you’re still missing files. It always happens, look in your backups and figure out what to add to the repository. Three, you forgot that there was a specific build order between a few random parts of your code. Write these down in your shell script / build script of choice so the end user doesn’t have to figure this out. Lastly, if you managed to get a clean VM/machine to compile on you’re going to find out that your environment isn’t setup right. If you require specific environment variables, list those in your build script so they get set. If you require other libraries be installed before yours, either define them as dependencies of your package, or atleast let the user know before you compile.

Now that your code compiles, make sure it compiles properly. What’s properly? Your code should compile on all target platforms that you’re willing to support. There’s a lot of little differences between compilers, and it’s possible to make most of them happy most the time. But, not only should your code compile, I should be able to link against it without warnings. If you don’t want to fix your warnings in the library (whats wrong with you?), at least fix all the warnings in your headers so that people can link against your code without warning spam. Why is this important? Because warnings usually mean something is wrong with the code, or at the very least ambiguous and error prone. That’s why a lot of places run with “warnings are errors” as a compile option. It helps to catch bugs, and make the code more clear. So what happens if you don’t fix those warnings? Your library is going to waste my time as I attempt to fix the warnings so I can integrate it. Or worse, you’re library is now a worthless waste of my time, and I’ll have to find something else.

So what started this rant? The Crypto++ library. It seems that the code was compiled with -Wno-unused to disable “un-used function parameters”, which would be fine if I was also going to use that compiler flag. Since I’m not, I have to either deal with all the warnings, or go fix them. Well, I’d like see my own warnings and errors, so looks like I have to go fix the library…

Copyright © 2002-2019 Travis Sanchez. All rights reserved.