[webkit-dev] It's time to remove the Haiku port

[Ryan Leavengood]

On Fri, Nov 4, 2011 at 5:40 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>
> Hopefully we will start writing more and more tests as reftests, to
> address the first category. Moving to one of the existing cross-port
> build mechanisms like GYP or CMake would help.

Yeah I will attempt to make use of GYP myself for the Haiku port,
except I'll need to add a new backend to generate Jamfiles, since Jam
is the preferred Haiku build system.

> Changes to core platform code in the third category are hopefully
> pretty rare, and I think you're just out of luck for the fourth
> category, but hopefully they're done in a modular manner and at least
> easy to enable/disable for a while.
>
> I think the more feedback we can get on what sorts of things you do
> have to do to keep up to date, the better things will get.

For additions to platform, I think a harmless default implementation
should suffice. Having to add an empty method to a port just to
satisfy the compiler seems like a lot of trouble. I can't find a good
example at the moment, so maybe it really isn't an issue.

Looking over some of the changes made to the Haiku port by non-Haiku
people just shows a lot of renames and changing of method arguments
and return values in the platform directory. This tells me that
platform really isn't any sort of API (and yes I know it isn't meant
to be) but maybe it should be? I personally would like to see WebCore
evolve into being as self-contained as possible, with clear APIs for a
platform to attach to. Maybe the new Platform directory will be the
start of this, and if so, I applaud the effort. Right now the platform
coupling is pretty bad. I hope one day #if PLATFORM(X) doesn't exist
in WebCore, at least not where such code adds a class member or
methods to core platform classes.

-- 
Regards,
Ryan