[webkit-dev] Some thoughts about platform flags

[Maciej Stachowiak]

On Sep 24, 2008, at 12:14 PM, Amanda Walker wrote:

> Hello all,
>
> A conversation started on https://bugs.webkit.org/show_bug.cgi?id=20890 
>  that Alexey suggested moving to webkit-dev, so here we go :-).
>
> One of the things we ran into when bringing up the Chromium  
> application architecture was that we needed to distinguish between  
> "platform" and "application features".  We took our cue from Apple's  
> combination of using PLATFORM(WIN) + PLATFORM(CG) for their windows  
> port, and created PLATFORM(SKIA) for the graphics library we're  
> using, and have started using PLATFORM(CHROMIUM) to denote "hosted  
> in a rendering subprocess, not a conventional view hierarchy"  
> independently of the OS and graphics API.
>
> So for example, we'd like to continue to use PLATFORM(CG) to denote  
> "we're using CoreGraphics", PLATFORM(MAC) to denote "we're building  
> for Mac OS X", but add build-time control over things (primarily in  
> WebCore) that make application assumptions like "crawl up the view  
> hierarchy, test to see if our grandparent view is a particular  
> class, and send it a message".  We've been intending to use  
> PLATFORM(CHROMIUM) for a bunch of this, but since the same issues  
> are likely to come up for other ports (embedded ports, a variation  
> on an existing platform that wants to render directly to a bitmap or  
> texture, etc.), it would be great to get input from others,  
> especially people working on other platforms & ports.
>
> We'll probably continue with our current approach for the moment,  
> since it does have precedent, but we won't be the last to run into  
> this issue, so if there's a better way, We'd love to start figuring  
> out what it would be.

Here's a few of my thoughts, as the person who introduced the  
PLATFORM() macro system as we know it:

1) PLATFORM macros should primarily be about use of particular  
underlying libraries technologies that a port sits on top of. When it  
is necessary to compile differently for the sake of particular  
features, I think it would be more appropriate to use an ENABLE or USE  
macro. Given this, PLATFORM(CHROMIUM) does not make sense to me, as it  
names a browser using WebKit, not a set of underlying libraries. It  
also would likely mean pretty different things on Mac and Windows, if  
you intent to use CG instead of Skia on Mac for instance. If this  
define is meant to represent "hosted in a rendering subprocess", then  
it should be called ENABLE(MULTIPROCESS) or something along those lines.

Right now the only use I see of PLATFORM(CHROMIUM) in WebCore is to  
define USE(V8), which is then not ever used. Using V8 seems unrelated  
to the "hosted in a rendering subprocess" concept you described.


2) USE(NSURLRESPONSE) does not fit the concept of platform macros  
either. It's not about using an underlying library like CURL or  
pthreads or Qt's unicode support. And NSURLRESPONSE is a poor name for  
the feature; if it's about the network library overall, that's not a  
very good name, and if it is about this one use, the class involved  
isn't even NSURLResponse.

I would like to understand the broader context a bit. Does the  
Chromium Mac port intend to use a different network back end? If so,  
then probably all networking code currently under PLATFORM(MAC) should  
be placed under USE(NSURLCONNECTION) to parallel USE(CFNETWORK) or  
USE(CURL). However, that should be done for all the NSURLConnection  
networking code, not just this one place. Maybe there is some other  
reason you wish to disable this client callback, if so, please  
clarify. I think the concept of a build that uses the Mac GUI-level  
code but some other network library instead of NSURLConnection makes  
sense and in other cases, network libraries use a separate feature  
define from the GUI-level PLATFORM macro.


3) PLATFORM(MAC) is not in any way the equivalent of PLATFORM(WIN_OS),  
that would be PLATFORM(DARWIN). The latter two, like PLATFORM(LINUX),   
represent low-level OS dependencies, below the GUI layer, and would be  
used even by ports which were based on a cross-platform GUI toolkit.


4) What has sort of evolved with the platform macros is that there is  
a "primary" one that generally drives settings of subsidiary macros.  
The "primary" platform is either a GUI toolkit or a platform with a  
specific strong assumption of GUI toolkit. PLATFORM(GTK), PLATFORM(QT)  
and PLATFORM(WX) all follow this concept fairly well. However,  
PLATFORM(WIN) and PLATFORM(MAC) are a little confused in various ways.  
Currently Apple's windows port is defined by the combination of  
PLATFORM(WIN) and PLATFORM(CG).

There should probably be an overall PLATFORM(WIN_APPLE) or the like  
which defines the port that runs on Windows and uses Apple's various  
ported libraries. Or perhaps WIN_CG or WIN_CGCF to make it more about  
technology and less about company name.

Similarly, PLATFORM(MAC) mixes together use of Cocoa, use of other  
underlying Objective-C or even C libraries that are only on the Mac,  
and being a primary port define. I think this define should be  
primarily about use of Cocoa and if there are ports that wish to use  
Cocoa but not other underlying technologies then we should consider  
splitting them out into their own USE or PLATFORM macros.


Anyway, I don't think we want to end up with a bunch of #if  
PLATFORM(MAC) && !PLATFORM(CHROMIUM), so let's pause for a second to  
think about what Chromium's version of the Mac port would want to do  
differnetly, what the reason for those differences is, and based on  
that what new PLATFORM/USE/ENABLE macros should be introduced. Can any  
of the Chromium folks give an overview?


Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080924/6ac7f4d4/attachment.html