> Does the new patchmaker still understand the .diff, .chromediff and > .files file from an old installed patchmaker? I ask because I have a > number of outstanding patches and if I have to upgrade my patchmaker I > don't want to lose these.
Good question. In principle, yes - but the changes to the format of chromelist.txt may confuse it. To tell the truth, I haven't tested this - I simply haven't had time. Back up your data directory and give it a go :-) >>One of the changes to Patch Maker 2 makes it more compatible with the >>layout of unjarred chrome in tarballs. This meant a change to the format >>of the chromelist.txt file which ships with nightlies. Unfortunately, >>this change is not backwardly-compatible. Patch Maker 0.75 will not work >>with nightlies from 2002-02-17 onwards, and Patch Maker 2.0 will not >>work with nightlies before that date. > > Will patch-maker ignore lines that it doesn't understand in a > chromelist.txt file? It will ignore lines prefixed with # or @, for backwardly- and forwardly-compatible reasons. Before 2.0 final, it may do more things. > I ask because I have some implementation thoughts on how to allow > patch-maker to add completely new files in chrome patches. I haven't > tried to implement it yet, but I think the theory is sound. It goes > something like this: > > 1) When generating chromelist.txt from the jar.mn files, add a line at > the beginning indicating which jar.mn file contained these lines. For The incompatible changes were to add this information - unjar now unjars each jar into a directory named after itself, to match the layout of tarballs. > 2) In the pma command, if the file cannot be found in the chromelist, > offer the opportunity to add it as a completely new file. If the user > accepts this option, they must specify a "guide file" which would be a > file that *does* exist in chromelist, in the same location as the new > file being added. The location to put the new file in the build tree, > and which jar.mn to add it to, would be taken from this guide file. That's an interesting idea. However, this feature (as you describe it) would add a great deal of complexity to the code. Gerv
