* gcc-changelog/git_commit.py: Add trailing '/'
for libdruntime. Allow empty changelog for
only ignored files.
* gcc-changelog/test_email.py: New test for go
patch in ignored location.
* gcc-changelog/test_patches.txt: Add test.
2020-05-22 Jakub Jelinek <jakub@redhat.com>
* gcc-changelog/git_commit.py: Add trailing / to
gcc/testsuite/go.test/test and replace gcc/go/frontend/
with gcc/go/gofrontend/ in ignored locations.
* gcc-changelog/git_commit.py: Add author_tuple
only if not present in author_lines.
* gcc-changelog/test_email.py: New test.
* gcc-changelog/test_patches.txt: Add new patch.
* gcc-changelog/git_commit.py: Refactor to make flake8 happy.
* gcc-changelog/test_email.py: Add new test.
* gcc-changelog/test_patches.txt: Add new patch.
git-check-commit.py does not know about "Reviewed-by",
"Reviewed-on", and "Signed-off-by" lines and hence it
expects those lines which follow the ChangeLog entries
to be indented by a tab.
This commit makes the script skip those lines. No further
processing is attempted because the review information
is not part of the ChangeLogs.
contrib/
2020-05-20 Frederik Harwath <frederik@codesourcery.com>
* gcc-changelog/git_commit.py: Skip over lines starting
with "Reviewed-by: ", "Reviewed-on: ", or "Signed-off-by: "
* gcc-changelog/git_commit.py: Support cherry pick
prefix.
* gcc-changelog/test_email.py: Test it.
* gcc-changelog/test_patches.txt: Add new patch.
* gcc-git-customization.sh: Add gcc-backport.
contrib/ChangeLog:
2020-05-15 Martin Liska <mliska@suse.cz>
* gcc-git-customization.sh: Add
alias.gcc-mklog new hook.
* mklog.py: New file.
* test_mklog.py: New file.
This commit is for the benefit of GDB, but as the binutils-gdb
repository shares the contrib/ directory with gcc, this commit must
first be applied to gcc then copied back to binutils-gdb.
This commit extends the two scripts contrib/dg-extract-results.{py,sh}
to handle some new, GDB specific test result types. These test
results types should never appear in GCC, or any other tool that
shares the contrib/ directly, so this change should be harmless.
In this patch series:
https://sourceware.org/pipermail/gdb-patches/2020-April/167847.html
changes were made in GDB's use of Dejagnu so that two additional
conditions could be detected, these are:
1. Test names that contain either the build or source paths. Such
test names make it difficult to compare the results of two test runs
of GDB from two different directories, and
2. Duplicate test names. Duplicates make it difficult to track down
exactly which test has failed.
When running Dejagnu on GDB we can now (sometimes) see two additional
test result types matching the above conditions, these are '# of paths
in test names' and '# of duplicate test names'.
If the test is run in parallel mode (make -j...) then these extra test
results will appear in the individual test summary files, but are not
merged into the final summary file.
Additionally, within the summary file there are now two new types of
test summary line, these are 'PATH: ...' and 'DUPLICATE: ...', these
allow users to quickly search the test summary to track down where the
offending test names are. These lines are similarly not merged into
the unified gdb.sum file after a parallel test run.
This commit extends the dg-extract-results.* scripts to calculate the
totals for the two new result types, and to copy the new test summary
lines into the unified summary file.
contrib/ChangeLog:
* dg-extract-results.py: Handle GDB specific test types.
* dg-extract-results.sh: Likewise.
* gcc-changelog/git_check_commit.py: New file.
* gcc-changelog/git_commit.py: New file.
* gcc-changelog/git_email.py: New file.
* gcc-changelog/git_repository.py: New file.
* gcc-changelog/git_update_version.py: New file.
As Iain reported, my change broke the case when one has bison >= 3,
but make decides there is no reason to regenerate plural.c, unfortunately
that seems to be a scenario I haven't tested. The problem is that
the pregenerated plural.c has been generated with bison 1.35, but when
config.h says HAVE_BISON3, the code assumes it is the bison3 variant.
What used to work fine is when one has bison >= 3 and plural.c has been
regenerated (e.g. do touch intl/plural.y and it will work), or when
one doesn't have any bison (then nothing is regenerated, but HAVE_BISON3
isn't defined either), or when one has bison < 3 and doesn't need to
regenerate, or when one has bison < 3 and it is regenerated.
The following patch fixes this, by killing the HAVE_BISON3 macro from
config.h, and instead remembering the fact whether plural.c has been created
with bison < 3 or bison >= 3 in a separate new plural-config.h header.
The way this works:
- user doesn't have bison
- user has bison >= 3, but intl/{plural-config.h,plural.c} aren't older than intl/plural.y
- user has bison < 3, but intl/{plural-config.h,plural.c} aren't older than intl/plural.y
pregenerated !USE_BISON3 plural.c and plural-config.h from source
dir is used, nothing in the objdir
- user has bison >= 3 and intl/plural.y is newer
Makefile generates plural.c and USE_BISON3 plural-config.h in the
objdir, which is then used in preference to srcdir copies
- user has bison < 3 and intl/plural.y is newer
Makefile generates plural.c and !USE_BISON3 plural-config.h in the
objdir, which is then used in preference to srcdir copies
I have tested all these cases and make all-yes worked in all the cases.
If one uses the unsupported ./configure where srcdir == objdir, I guess
(though haven't tested) that it should still work, just it would be nice
if such people didn't try to check in the plural{.c,-config.h} they have
regenerated.
What doesn't work, but didn't work before either (just tested gcc-9 branch
too) is when one doesn't have bison and plural.y is newer than plural.c.
Don't do that ;)
2020-04-16 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/92008
intl/
* configure.ac: Remove HAVE_BISON3 AC_DEFINE.
* Makefile.in (HEADERS): Add plural-config.h.
(.y.c): Also create plural-config.h.
(dcigettext.o loadmsgcat.o plural.o plural-exp.o): Also depend
on plural-config.h.
(plural-config.h): Depend on plural.c.
* plural-exp.h: Include plural-config.h. Use USE_BISON3 instead
of HAVE_BISON3.
* plural.y: Use USE_BISON3 instead of HAVE_BISON3.
* configure: Regenerated.
* plural.c: Regenerated.
* config.h.in: Regenerated.
* plural-config.h: Generated.
contrib/
* gcc_update: Add intl/plural.y dependency for intl/plural-config.h.
Whilst trying to convert the add vendor branch script to work with
personal branches I encountered a minor issue where git would report
ambiguous refs when checking out the new branch.
It turns out that this is because git considers <me>/<topic> to be
ambiguous if both
refs/heads/<me>/<topic>
and
refs/remotes/<me>/<topic>
exist in the list of known branches.
Having thought about this a bit, I think the best solution is to adopt
something more like the vendors space and call the remote users/<me>
(this also works better if you want to set up remotes to track other
users branches as well).
So this patch has two parts.
1) It updates gcc-git-customization.sh to set up the new 'remote' and
converts any existing remote and branches tracking that to the new
format
2) It adds a new script to set up a personal branch on the gcc git repository.
* gcc-git-customization.sh: Use users/<pfx> for the personal remote
rather than just <pfx>. Convert any existing personal branches to the
new remote.
* git-add-user-branch.sh: New file.
This script is intended to create a new vendor branch. Doing so is
not completely obvious if you are not familiar with the upstream
structure, so this takes the pain out of getting it right.
It doesn't check out the branch locally, but does set everything up so
that, if you have push enabled for your vendor branches, then
git push vendors/<vendor> <branch>
will work as expected.
Run the script as
contrib/git-add-vendor-branch.sh <vendor>/<branch> <start-point>
the <vendor> space must have previously been set up in the way
git-fetch-vendor.sh expects.
* git-add-vendor-branch.sh: New file.
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
Really old git versions (like 1.6.0) require
"git log --pretty=tformat:%p:%t:%H"
or else we see:
Updating GIT tree
Current branch master is up to date.
fatal: invalid --pretty format: %p:%t:%H
Adjusting file timestamps
Touching gcc/config.in...
Touching gcc/config/arm/arm-tune.md...
...and an empty revision in LAST_UPDATED and gcc/REVISION.
In its absence, for newer git versions, "tformat" is the default
qualifier, documented as such default for at least git-2.11.0.
As discussed on IRC, this adds a couple more checks in the
customization setup for git. If the variables user.name and
user.email are not set anywhere in the git config hierarchy, we set
some local values. We always ask about the values we detect and if
the user gives an answer that is new, we save that in the local
config: this gives the opportunity to use different values to those
configured for the global space.
Also cleaned up a couple of minor niggles, such as using $(cmd) rather
than `cmd` for subshells and some quoting issues when using eval.
* gcc-git-customization.sh: Check that user.name and user.email
are set. Use $(cmd) instead of `cmd`. Fix variable quoting when
using eval.
The monotonically increasing revision ids need to be globally unique, so they should
only identify commits that were committed to the upstream repo to its master or
releases/gcc-N branches. The alias could print something even for private branches
or vendor branches etc., but if such an identifier is then used publicly, it will
refer to something else.
2020-01-16 Jakub Jelinek <jakub@redhat.com>
* gcc-git-customization.sh: Verify the id to be printed is ancestor of
the corresponding remote release branch (or master), otherwise print
nothing.