![]() | Ned Batchelder : Blog | Code | Text | Site Modifying library code » Home : Blog : March 2006 |
Modifying library codeTuesday 14 March 2006 One of the joys of developing software these days is being able to build on top of high-quality libraries. Finding just the right package to solve one of your problems can remove a huge burden from your development shoulders. Unfortunately, sometimes you experience the disappointment of realizing your beloved library has a flaw. A bug, a missing function, whatever. Then you have to try to fix it. If you don't have the source, forget it, you have to work around it. But if you do have the source, do yourself a favor: before modifying the code, put in some protection to make sure your product really is using the modified source. The problem with modifying library code is that you shift from using the library as shipped to using your modified version, and subtle changes is build or deploy environments can switch you between the two without even knowing it. For example, modified include files have to be found in a product tree before searching the standard include directories. So the first modification to the library should be to mark it as your modified version, and your product code should assert that it is using the modified library. For example, in C++, in one of the headers, add a macro definition: // ReportGeneratorLib.h header file Then in your code where you include the library, check that you have the right version: // Initech TPS Report system This way, if a build machine's configuration changes, or a new devloper doesn't set up his enviroment properly, a very visible error message will appear, rather than subtle bugs manifesting themselves. The same technique can be used in Python. Mark the library file: # ReportGeneratorLib.py and then assert in the product code: # Initect TPS Report system It's a very simple technique, but can save headaches later, after you've long forgotten about having made the changes to the libraries.
tagged:
development» 4 reactions | |
Comments
Nice technique. My only observation would be that you don't necessarily need to modify the production code, but you do need to add that assertion in the unit tests for the code that is using that library. You could for example add the assertion in the setup method of your unit test module(s), so that it's picked by any unit test function/method that's exercising that code.
Grig
Brilliant! Why the !#$!@ haven't we been doing this all along at my company. *slaps forehead*
I do it both ways:
1. some stuff gets patched in source. I maintain either diffs or vendor-branches in Subversion
2. all of the rest of our monkeypatching is done from one module.
Great idea. My solution has been to rename the library file. Which causes a lot of changes to import/include statements throughout the code. (Of course this can be done automaticly)
Add a comment: