Many of you probably know what the expression "eating your own dog food" means as it relates to software development. But for those who are worried that I may have gone off the deep end when I titled this post, let me provide some explanation.
In software development if an organization "eats its own dog food", it's using for its own purposes the same software that it produces and markets. For example, the team that writes the Eclipse IDE and tool set uses Eclipse to develop Eclipse.
This post describes one way in which Objective Systems makes use of some of its own software. Currently the Windows SDK kits for our ASN1C product include libraries and DLLs in folder hierarchies named "c" and "cpp". For example, there is a clib folder and a cpplib folder. The libraries and DLLs that are in these folders are built with Visual C++ 6 using nmake and makefiles. There are other folder hierarchies for other platforms, so you would also see folders like c_vs2005, cpp_vs2008, and so on.
For ASN1C 6.5, which is currently in development, we're planning on making a couple changes related to these libraries and DLLs. First, instead of building them with Visual C++ 6, which is getting a little long in the tooth now, we're going to build them with Visual Studio 2008. And second, instead of using nmake and makefiles, we're going to use msbuild and Visual Studio project files (.vcproj files). Visual C++ 6 libraries will still be included, but in folder hierarchies named c_vc6 and cpp_vc6.
If you're familiar with ASN1C on Windows, you know that there are frequently several variations of libraries and DLLs provided. Some are built without optimizations (in the lib folder), and some are optimized (in the lib_opt folder). Some of the libraries are built against Microsoft's run-time DLLs (those with "md" in the name), and others are built against Microsoft's run-time libraries.
In addition some libraries and DLLs are built so they're restricted to a fixed set of named hosts that are in the customer's license file. Others are built so they don't have this restriction. The libraries and DLLs that a customer gets depend on what type of license the customer has purchased.
With numerous variations in how the various libraries and DLLs are built, we frequently generate different makefiles using one makefile as a base. This approach allows us to maintain a fairly small number of makefiles in our software control system.
With ASN1C 6.5 we're facing the same challenge with Visual Studio 2008 project files. We want to minimize the number of actual .vcproj files that we have in our software control system, but we still have numerous variations in how we need to build the various libraries and DLLs.
This blog post discusses how we're solving this problem in relation to the .vcproj files that we need in order to build the restricted run-time binaries; i.e., those libraries and DLLs that will only run on the hosts specified in the customer's license. These restricted libraries and DLLs are built very similarly to their unrestricted counterparts, but there are some adjustments that need to be made. So we were confronted with a situation where we had the .vcproj files to build the unrestricted libraries and DLLs, and we needed corresponding .vcproj files to build the restricted libraries and DLLs.
Visual Studio 2008 .vcproj files are XML files, and Microsoft publishes the schema for them. So we used our XBinder product to generate C# code based on this schema. Then we wrote a C# utility to decode the unrestricted .vcproj files, make the necessary adjustments using the generated class definitions, and then encode the restricted .vcproj files. It works like a charm, and it didn't take very long to write it.