On 22/11/18 5:56 AM, Richard Stallman wrote:
That is very sophisticated, and perhaps that means it will not be
fooled by simple things that fool the git commands for finding
differences.
However, it might get totally messed up by macros that syntactically
don't parse like valid code. Have you tried such cases?
If it has a problem like that, it might not be valid in general,
but it might nonetheless be valid for Glibc if Glibc never has
such macros.
There are a couple of cases like that in glibc (mostly in function
arguments) and I've been able to work around them. I am going to
continue improving this at least up to the 2.30 release (that's August
next year), so that's enough time for people to send in use cases that
break for them if other projects are interested in incorporating this
script. As far as glibc is concerned the script seems to catch all the
oddities in its recent history (i.e. the last 2 years).
> - Changes within function definitions, struct members. The script only
> knows that it changed, not what changed inside.
In general, it requires human intelligence to describe WHAT was changed.
True, I can see this improving a bit more (maybe a very motivated intern
could take a stab at this) but not a lot.
If you think this is a good start, I'd like to install this in glibc so
that we don't have to maintain a ChangeLog file after the 2.29 release
in February. It will go through a proper technical review among glibc
maintainers and we can then iterate on the script in the glibc tree as
people find additional gotchas with them.
Siddhesh
