On Fri, 28 Dec 2018, Sandra Loosemore wrote: > Taken individually, all these changes probably qualify as obvious, but given > how extensive they are and how many files are touched, I thought it would be > good to get a sanity check on methodology before checking in the whole pile. > E.g. are there other files that should be excluded from the recipe for part 1?
gcc/go/gofrontend/ and libgo/ have their own commit processes involving applying fixes to another repository first (and no ChangeLogs). Unfortunately the URL to that repository in gcc/go/README.gcc and libgo/README.gcc no longer works. I think the same applies to gcc/d/dmd/, though I'm not sure the process there is documented anywhere. Likewise for parts of libphobos (although that has a ChangeLog for the GCC-local build machinery). The .po files come verbatim from the Translation Project; it's useless to patch those locally in GCC since the changes will be overwritten by the next copy from the TP. gettext's fuzzy match machinery should suffice to help translators match their old translation of a "can not" message to the new "cannot" message. I don't really think patching such issues in testcases is useful; certainly not for the ACATS tests coming from an upstream source. (Testsuite .exp files would be more like normal sources in this regard and should get spelling fixes etc., but I don't see any such files affected by your changes.) libtool.m4 and ltmain.sh come from upstream libtool; this seems like an issue that should be fixed there (if still present, our libtool version is very old), not patched locally in GCC. Not patching libtool.m4 locally might eliminate at least some of the configure regenerations. For tm.texi, make sure the changes exactly correspond to the result of regenerating given the target.def changes. For changes to include/ and libiberty/, it's helpful to apply them to binutils-gdb at the same time as GCC (the shared files and directories aren't always exactly in sync between the two repositories, but should be, and I'd consider copying a change from one to the other to be obvious). -- Joseph S. Myers jos...@codesourcery.com
