On Fri, Nov 4, 2011 at 5:40 PM, Dirk Pranke <dpra...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
