This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] ChangeLog generation script
- From: Khem Raj <raj dot khem at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Mon, 19 Nov 2018 15:18:31 -0800
- Subject: Re: [RFC] ChangeLog generation script
- References: <email@example.com>
On Mon, Nov 19, 2018 at 11:57 AM Siddhesh Poyarekar <firstname.lastname@example.org> wrote:
> I am back from under my rock with a draft of the ChangeLog generation
> script. I've had this ready for a while but was trying to make it run
> faster - it currently takes a little under 30 seconds to generate the
> ChangeLog between glibc-2.27 and glibc-2.28. I hae a few ideas to
> reduce the time spent (like using git diff -U100000 instead of the two
> files) but I can pursue them after the script has gone in as well.
> At a high level the script accepts two inputs, a from-ref and a to-ref
> and generates a ChangeLog like output between these refs. Note that
> this is not a proper ChangeLog; it provides a lot of the information
> that a ChangeLog would give and some additional information in context
> of its origin, i.e. the git history.
> The script goes through each ref in the range and for each ref, gets the
> before and after refs of each change. For non-C code (i.e anything that
> is not *.c or *.h), it indicates whether the file was added, deleted,
> modified or renamed.
> For C code, it goes further for modifications and renames where the old
> and new file are not identical, by generating parse trees for the old
> and new files and compares those trees to generate a source level ChangeLog.
> What it can detect:
> - Adds, modifications, renames and deletions.
> - Top level objects like static variables, function declarations and
> definitions, structs and unions and assignments.
> - Nesting within macro conditions. It's not perfect, but pretty decent.
> What it cannot do yet:
> - Detect changes to comments. It's just dropping all comments right
> now, so changes that are comment-only end up seeming identical.
> - Changes within function definitions, struct members. The script only
> knows that it changed, not what changed inside.
> - Weird macro nesting will break things. I tried to adjust for some
> weirdness that I encountered in my testing, but I am confident that an
> 'innovative' C programmer can break this.
> Overall I reckon that this is good to go in terms of concept, but that's
> only because I'm the script's mommy and mommies always think their
> babies are the best.
> Comments welcome!
its a promising start. Have you looked into