I'm not picking on John, who, by submitting working code changes that solve real problems has earned himself a free beer if he and I are ever within walking distance of the same watering hole. I would, however, like to point out that there are a number of gotchas to be aware of in creating and applying patches for open source packages, mostly simple stuff that just happens to be unfamiliar to many VMS folks. Apologies to those who already know all this, but I'm taking this opportunity to review what folks working on VMS systems need to do to create patches using GNU diff and apply those patches using GNU patch.
The basic procedure is similar to creating a set of machine-readable changes via DIFFERENCES/SLP and then applying those changes with the SUMSLP editor via EDIT/SUM. GNU patch is considerably more flexible than EDIT/SUM, however. For starters, it can modify any number of files from one patch, and it can use contextual information to apply patches to sections of code that are no longer in precisely their original locations. The Perl patching guidelines are here: http://www.perldoc.com/perl5.8.0/Porting/patching.html Other open source packages may have other requirements, but that's pretty typical. I've interspersed some more comments below as responses to John, but the documentation that comes with the diff and patch utilities covers much more than what I'm sketching out here. At 9:55 PM -0400 4/29/04, John E. Malmberg wrote: >Craig A. Berry wrote: >> >>>--- dist_root:[000000]configure.com_old Sun Apr 11 21:58:27 2004 >>>+++ dist_root:[000000]configure.com Sat Apr 24 22:31:30 2004 >> >> >>unless these filespecs are in unix syntax, folks who have check-in authority are >>not going to be able to apply it. > >I will have to use the bash shell to change the syntax. Not necessarily. You should be able to do the following from DCL if you have GNV installed: $ mcr gnu:[bin]diff -u /dist_root/configure.com_old /dist_root/configure.com You may want to define a "gdiff" symbol so you can use GNU diff from DCL without conflicting with the DIFFERENCES command. I use the GNU diffutils available from the Freeware 5.0 CD, which has the advantage over the GNV version of accepting the VMS version number even though that's not really unix syntax. It also has its own file redirection built in, so it doesn't depend on the shell for that. I typically use the version ;-0 syntax to indicate the earliest version so that I get the differences between the base version and whatever the latest change is. Here's an example: $ gdiff -u /sys$manager/sylogicals.com;-0 /sys$manager/sylogicals.com --- /sys$manager/sylogicals.com;-0 Tue Aug 15 18:36:42 2000 +++ /sys$manager/sylogicals.com Fri Oct 18 11:20:31 2002 @@ -416,6 +416,9 @@ $! $! Define any site-specific logical names below: $! +$ DEFINE/SYS/EXEC DCL$PATH GNU:[BIN] +$ DEFINE/SYS/EXEC VAXC$PATH GNU:[BIN] +$ DEFINE/SYS/EXEC VI_SECTION GNU:[LIB]VI_SECTION.TPU$SECTION $! $! $! ****************************************************************** $ If the filenames were in mixed case, I'd need to double quote the arguments or define DECC$ARGV_PARSE_STYLE. That's the easy part. The hard part is knowing what case the original filenames were in. Perl has a file called MANIFEST listing each file contained in the package; many other packages have something similar. This example only finds the differences to one file. While this method can be used to build up a patch one file at a time, the canonical way to find differences to a whole set of files is to maintain an untouched directory tree of the original sources and collect differences between that and the directory tree containing modified sources with something like: $ gdiff -"urN" orig_dir new_dir where "r" indicates that diff should recurse into subdirectories and "N" indicates that files missing from the original directory should be created by the patch. See the diffutils documentation for more detail. >The samba/rsync folks seem to be able to accept them. They are probably manually editing your patches before applying them or manually feeding the filenames to GNU patch when it can't find them and prompts for what file to patch. Or I suppose they could be applying them on VMS with the same rooted logical defined that you have. >Having never run a patch procedure, I do not know if it cares about >what is in the filename, but just uses it as a comment. After all, >those lines do not contain anything that the patch program needs to >apply the patch. Er, knowing which file or files to patch might be considered something the patch program needs in order to apply the patch. In some cases patch may use the date in the line beginning with "---" to determine whether it is patching the right version of a file, but for the most part it just uses the filename from the line beginning with "+++". This is one way GNU patch differs from EDIT/SUM. As far as I know the SUMSLP editor can only apply changes to one original source file at a time (though it can work its way through a list of difference files), and you have to explicitly tell it which file to update. Though GNU patch will prompt for filenames if it can't find the files, maintainers will normally expect that a properly constructed patch has the filenames in it, all relative to the same directory. I've by no means covered all the possibilities here, and there is room for individual variation and preference in the creation and application of patches, but I hope this gets folks started who considered this a great mystery. It isn't. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
