Re: [PATCH] haiku: Initial build support

[Joseph Myers <joseph@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]

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
joseph@codesourcery.com