Method to generate the list of binaries for automated packaging of Software patches based on the changed source code for C-language projects
Publication Date: 2010-Sep-17
The IP.com Prior Art Database
The present idea proposes to address the issue of automatically identifying a minimal list of affected files in order to package them as a software patch. This method proposes to use existing tools such as the makedepend, and existing infrastructure of projects like Makesystem of the source tree in a new way in order to infer into the list of packagable files that are affected. The method broadly involves the following: As a one time effort, generate a mapping for the whole project ( source tree): >The input to this step will be a list of all possible deliverable binaries/libraries/headers for the product ( refered to as deliverables ) >The first step is to use makedepend to get the dependencies that c files have on header files. >The Makefiles themselves contain pre-requisite dependencies. i.e a binary’s dependency on source files. >Extract all the “target: dependency” lines from all the makefiles and create a new file. (Filter out other commands) This file will act as the input to the next steps. >For each possible source file ( c or header file in the projects source tree ), use the file created above to create a reverse dependency listing. i.e a listing from source file to final binary using the files created above. The steps mentioned above are a one time effort of creating a mapping. This mapping will have to be updated only if there are significant changes. i.e If new components, new files are created etc.
Method to generate the list of binaries for automated packaging of Software patches based on the changed source code for C -language projects
Software products/solutions of sufficient size and complexity do have bugs in them. This is a fact of life. The providers continually fix the bugs which are reported by customers. They also keep enhancing parts of the products that are found wanting.
Customers may demand immediate fixes for the bugs or may need the enhancements immediately. In such cases, a separate release/version of the product cannot be planned. Software Patch fixes are a common way to ship such bug fixes or enhancements to customers. This a patch should contain only the files (binaries ) that have been affected by the source code changes which fixed the bug. It is completely unnecessary to re-ship the entire product as part of the patch-fix.
Such a patch could contain libraries, configuration files, and even header files apart from binary executables.
There are different ways of providing patches. We may choose to just zip/ tar the files and ship them directly, or it could be based on the native installers of the particular platform( like smit/installp on AIX). It could even be a sophisticated self-extractable utility which just overlays the patch on top of the product.
If we are to automate the packaging of the patch, we have to be able to automatically pick up only those files that have been affected by the source code changes.
One would normally use the make system to incrementally generate only the affected binaries. In a small project, we could pickup only the newly generated files based on the changed time stamp.
In the real world, this may not be possible for the following reasons
-A bigger project may have thousands of .c and header files. In such scenarios, using the timestamp may not be entirely foolproof.
-A real world project could typically use a rolling tree - where a newer and newer patches are being updated on a released version of the product. This complicates things
-Also there may be many reasons to build the entire binary set afresh from the source. It may be less efficient to maintain the previously generated binaries for all versions of the
product for each platform that is supported and on each service patch level
( PTF level )
One more way to create patch-fixes could be to compare (diff) the generated tree with an old tree (old tree @ a predefined base line or released level) to deduce the newly generated files. However, in general there is no external tool to compare to 'binaries'. i.e. There's no way to find out if there is any logical change that went into the binary, or it was just a rebuild and hence a change in internal timestamps. It would in general get very complicated if one has to identify is there are indeed some functional differences in the files
Step 1: Use 'makedepend' in ach component of the source tree. Concatenate the output of 'makedepend' with...