This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] haiku: Initial build support
On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers <firstname.lastname@example.org> wrote:
> 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.
>> 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
> 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
A lot of such information seems to come out from a number of reviewers
only during patch review from new contributors. Would you mind
improving https://gcc.gnu.org/contribute.html and especially around
"Testing patches" or start something like the glibc contribution
checklist on the wiki that actually makes a lot of this easy to find
rather than searching in mailing list archives for new contributors ?
>> 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