On Mon, 16 Jul 2018, Alexander von Gluck IV wrote: > * We have been dragging these around since gcc 4.x. > * Some tweaks will likely be needed, but this gets our foot > in the door. > > Authors: > Fredrik Holmqvist > Jerome Duval > Augustin Cavalier > François Revol > Simon South > Jessica Hamilton > Ithamar R. Adema > Oliver Tappe > Jonathan Schleifer > .. and maybe more!
Before this can be reviewed, we'll need copyright assignments (with employer disclaimers where applicable) on file at the FSF from everyone who contributed a legally significant amount of code (more than around 15 lines). Without those, reviewers can't safely look at the changes in detail. https://gcc.gnu.org/contribute.html https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future Then, please make sure that only substantive changes are included - that there are no diff lines that are purely changing trailing whitespace in existing code, for example. Please ensure that all copyright and license notices follow current standards (which means using ranges of years ending in 2018, GPLv3 notices and a URL not an FSF postal address). For changes to existing code, especially, please make sure to include sufficient rationale in the patch submission to explain those changes, why they are needed and the approach taken to them. For new target OS support, I'd expect details to be provided of the test results on that OS for the various architectures supported by GCC. Are you planning, if the support is accepted in GCC, to maintain a bot that keeps running the GCC testsuite for GCC mainline for this OS for the various target architectures supported, at least daily or thereabouts, and posts the results to the gcc-testresults list, and to keep monitoring the test results and fixing OS-specific issues that show up? It's much better for issues to be identified within a day or two of the commit causing them than many months later, possibly only after a release has come out with the issue - but that requires an ongoing commitment to keep monitoring test results, posting them to gcc-testresults and keeping them in good shape. > diff --git a/libtool.m4 b/libtool.m4 If this an exact backport of a change from upstream libtool git? If so, please give the commit reference. If not, give the URL of the submission to upstream libtool. We don't want local libtool changes that aren't backports or at least proposed upstream without objections, to avoid making future updates from upstream libtool harder. -- Joseph S. Myers jos...@codesourcery.com
