[webkit-dev] Some thoughts about platform flags

Wed Sep 24 15:39:04 PDT 2008

[resent from an address mailman knows about]

On Wed, Sep 24, 2008 at 3:36 PM, Darin Fisher <darin at google.com> wrote:

> On Wed, Sep 24, 2008 at 2:16 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> 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=20890that 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.
>>
>
> Actually, we do have a set of underlying "libraries" corresponding to the
> base/ and net/ directories in the chromium source.  Our webkit port
> leverages elements of those modules.  We have to decide if a
> PLATFORM(CHROMIUM) implies a dependency on those modules or if we should
> instead move our port to not depend on those modules by introducing another
> abstraction layer.  (I suspect that an additional abstraction layer is a bad
> idea.)
>
>
>
>> 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.
>>
>
> I don't think anything about our port implies hosted in a rendering
> subprocess.  Our port works perfectly well in a single process traditional
> browser model.  We build two embedding apps based on our port of WebKit:
>  test_shell and chrome.  The former is like a mash-up of DRT and Spinneret.
>
> Our port satisfies many of the requirements of a multiprocess rendering
> engine, but it also satisfies many of the requirements of a headless WebKit
> (a.k.a. rendering to memory, sans-widget system).
>
> At the moment, much of our port leverages the PLATFORM(WIN), but in many
> cases that was done to reduce the forking of WebCore.  So, we have some work
> to do to disentangle our overuse of PLATFORM(WIN).  Porting chromium to mac
> and linux is a forcing function for much of that cleanup.
>
>
>
>>
>> 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.
>>
>
> We don't use PLATFORM(CHROMIUM) that much yet.  I agree that USE(V8) is or
> should be completely orthogonal to things like PLATFORM(CHROMIUM).
>
>
>
>>
>>
>> 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?
>>
>
> Chromium will use the same network stack on all platforms.  From the
> point-of-view of WebKit, we implemented a ResourceHandle that just delegates
> to the embedder.  Our glue layer (our WebKit layer) provides an interface
> named ResourceLoaderBridge (how about that name eh!? ;-)
>
> So as you can see that "network stack" is very thin from the point-of-view
> of WebCore.  It is just a bridge.  At the layer we do take advantage of some
> types defined by our net/ module, however, so it is not completely without
> ties to the chromium platform.
>
>
>
>> 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?
>>
>
>
> I can go into further details, but maybe what I've written so far will
> spawn some more questions?
>
> -Darin
>
>
>
>>
>>
>> Regards,
>> Maciej
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080924/9119f19d/attachment.html 