[webkit-dev] Some thoughts about platform flags
mjs at apple.com
Wed Sep 24 16:25:30 PDT 2008
On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote:
> On Wed, Sep 24, 2008 at 2:16 PM, Maciej Stachowiak <mjs at apple.com>
> 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.
> 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.)
I'm not really familiar with what is in these libraries. Could you
give a brief outline?
> 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.
OK; that appears to disagree with what Amanda said above.
> 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
> We don't use PLATFORM(CHROMIUM) that much yet. I agree that USE(V8)
> is or should be completely orthogonal to things like
> 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.
Then it sounds to me like there should be a separate USE or PLATFORM
macro for NSURLConnection, separate from Cocoa/CG UI, since you want
the latter but not the former. It might also make sense to have a
separate macro for your network library. That would probably be better
than using PLATFORM(CHROMIUM) as a catchall, since as we are now
learning, having a single macro cover multiple arguably orthogonal
platform choices can create trouble down the road.
> 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?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev