mhd:

I think that if I had to automate that task, I'd generate the diffs automatically, then write a chain of small perl scripts to implement your rules by editing the diff patches. So rather than trying to build a big complicated program, generate your diff patches. Then, as you suggest in your idea: Figure out how to edit the diffs to accomplish your rules.

While Text::Diff appears to be a nice package, you might want to look at GNU diff, as it has a nice set of options. You can fine-tune its output, and even perform some filtering up-front, such as:

      -I RE  --ignore-matching-lines=RE
             Ignore changes whose lines all match RE.
[download]

For the rule to not edit the bytecodes: I'd scan the file containing the bytecodes for the beginning and ending lines of the bytecode array, and delete diff edits between those lines. (If you have control of the input file, you might add a BEGIN and END type of comment to simplify finding the code blocks you don't want patch to touch, otherwise, you may have to create a set of regexes.)

To add new prototypes from one file without deleting ones that are removed, simply remove any delete edits in the diff for those particular header files. So for this, you might have a list of files for which you remove all deletes.

Finally, regarding your question "Or is this attempt-to-automatize thing impossible to be done by machine?": Many times, text is just too free-form to automate everything. But getting a 90% solution is usually quick and easy. Then you need only raise an alert when the program doesn't know what to do for a specific case. I tend to do jobs like this iteratively. As I do a job, I try to find a way to automate either (a) the most annoying case, or (b) the simplest win. Then on the next iteration, I again find something annoying to automate...and so on. In just a few iterations, you'll probably get enough cases covered that you'll find weeks (months...) between alerts.

Be sure to write your code and/or documentation very clearly! Projects like this are the kind that are a "pick it up and put it down" sort. With infrequent edits to the program, you need to make sure you don't break any rules. I find unit-tests (in the mode of Test Driven Development) to be very helpful here. That way, you can make sure you don't break edits you've already handled.

I hope this helps...

...roboticus