I think you may want to look at openembedded and use their way to control those things, rather then a new idea. You can build webkit there too. Most of what you said "most" is a minor part to me, may be to others. rgds joe
--- On Tue, 5/5/09, Maciej Stachowiak <m...@apple.com> wrote: > From: Maciej Stachowiak <m...@apple.com> > Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs > To: mbe...@pleyo.com > Cc: webkit-dev@lists.webkit.org > Date: Tuesday, May 5, 2009, 11:19 PM > On May 4, 2009, at 5:21 AM, Mario Bensi wrote: > > > We pursued the same goal for a couple of years. Since > our porting > > targets are various middleware & CE platforms, we > had to identify and > > adapt WebKit needs at a better grained level than > platform. > > In order to do this we collected all dependencies in a > Browser > > Abstraction Layer (BAL directory). The configuration > is handled by a > > Base directory (definition of types, platform > specifications) and we > > use CMake to define platform specificities (and > it's a great cross- > > platform tool). > > > > Sure the BAL model has still improvements ahead of it, > but it has the > > merit of existing, being widely tester on a quite wide > range of > > targets, configurations and libraries. > > My understanding is that BAL injects a platform abstration > layer under the platform abstraction layer that is the > "WebCore/platform" directory. Also, I gather that > BAL tries to do more things via runtime indirection and > subclasses with virtual methods instead of WebCore's > compile-time approach. To me, those aspects sound like they > may not be good fits for our goals. But I would be glad to > hear more details about BAL, and how it would compare to my > proposal. > > Regards, > Maciej > > > > > > Regards > > Mario > > > > Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous > avez écrit : > >> I think our set of porting macros has become > somewhat confused. > >> > >> Originally, our idea was that a port represents > primarily adaptation > >> to a particular platform. However, over time it > has become clear that > >> most of what is decided by a port is not platform > adaptation, but > >> rather policy decisions. For example, ports decide > to have different > >> features enabled, or to use different sets of > system functionality on > >> the same underlying OS. > >> > >> In addition, I think the catchall top-level > PLATFORM create confusion, > >> because it is not totally clear if they are policy > decisions, platform > >> adaptation decisions, or what. > >> > >> Third, it seems wrong that the policy choices of > every port are > >> represented as a bunch of ifdef tomfoolery inside > a single Platform.h > >> file. > >> > >> And fourth, many ports often run on the same OS, > but with a different > >> set of choices - for example on Mac OS X it is > possible to build the > >> Mac, Chromium, Gtk, Qt and Wx ports (at least). > >> > >> > >> Therefore, I propose that we change as follows: > >> > >> 1) Strictly separate platform adaptation > (mandatory to run on a given > >> OS, compiler, or CPU at all) from policy choices > (what features to > >> enable, what optional libraries to use). > >> > >> 2) Phase out PLATFORM macros completely - each use > should be converted > >> to a policy choice, or a platform adaptation > decision. > >> > >> 3) Instead of ports being defined by a top-level > PLATFORM macro, I > >> propose that each port should have its own header > file to define > >> policy decisions. For example, I'd propose > that the system Mac OS X > >> WebKit should use PortCocoa.h, and the WebKit used > by Safari for > >> Windows should use PortWinCG.h. There may also be > a PortIPhone.h. > >> These port definition headers would live in their > own top-level WebKit > >> module. Each one would be completely owned by > whoever is generally > >> considered the "owner" of a given port. > Because related ports on > >> different platforms may wish to share policy > choices, it's ok for Port > >> headers to include shared headers for some > choices. For example, all > >> Apple-maintained ports may include PortApple.h. We > could go even > >> further and have PortDefault.h to make default > choices of what > >> features are enabled, that ports would have to > explicitly override. > >> > >> 4) Platform adaptation macros would still be > defined in Platform.h > >> based on sniffing the environment, this would > include things like the > >> compiler, the underlying OS, available libc > functions, and so forth. > >> > >> > >> Platform adaptation macros would be: > >> > >> OS() - underlying operating system; only to be > used for mandated low- > >> level services like virtual memory, not to choose > a GUI toolkit > >> Examples: > >> OS(UNIX) - Any Unix-like OS > >> OS(DARWIN) - Underlying OS is the base OS > X environment > >> OS(FREEBSD) - FreeBSD > >> OS(WIN) - Any version of Windows > >> OS(WINCE) - The embedded version of > Windows > >> > >> COMPILER() - the compiler being used to build the > project > >> Examples: > >> COMPILER(GCC) - GNU Compiler Collection > >> COMPILER(MSVC) - Microsoft Visual C++ > >> COMPILER(RVCT) - ARM compiler > >> > >> HAVE() - specific system features (headers, > functions or similar) that > >> are present or not > >> Examples: > >> HAVE(MMAP) - mmap() function is available > >> HAVE(ERRNO_H) - errno.h header is > available > >> HAVE(MADV_FREE) - madvise(MADV_FREE) is > available > >> > >> > >> Policy decision macros would be: > >> > >> USE() - use a particular third-party library or > optional OS service > >> Examples: > >> USE(SKIA) - Use the Skia graphics library > >> USE(CG) - Use CoreGraphics > >> USE(V8) - Use the V8 JavaScript > implementation > >> USE(CFNET) - Use CFNetwork networking > >> USE(NSURL_NET) - Use NSURLConnection-based > networking > >> USE(APPKIT) - Use AppKit views and events > >> USE(GTK) - Use Gtk+ > >> USE(QT) - Use Qt > >> USE(QUICKTIME) - Use the QuickTime media > engine > >> USE(QTKIT) - Use the QuickTime media > engine via the Mac QTKit > >> API > >> USE(QUICKTIME_WIN) - Use the QuickTime > media engine via its > >> Windows API > >> > >> ENABLE() - turn on a specific feature of WebKit > >> Examples: > >> ENABLE(ACCESSIBILITY) - Enable support for > assistive > >> technologies (currently wrongly a HAVE) > >> ENABLE(XSLT) - Include XSLT support > >> ENABLE(OBJC_MAC_API) - Include Objective C > API based on > >> NSViews (current WebKit Mac) > >> ENABLE(OBJC_DOM_API) - Include Objective C > DOM bindings (may > >> apply to other ObjC toolkits than AppKit) > >> ENABLE(JSC) - Enable use of the > JavaScriptCore implementation > >> (inconsistent with V8 because JSC is a WebKit > feature but V8 is an > >> external dependency, even though they serve > similar purposes) > >> ENABLE(VIDEO) - Enable support for the > HTML5 Video element > >> ENABLE(SVG) - Enable support for SVG > (Scalable Vector Graphics) > >> ENABLE(WML) - Enable support for WML > >> > >> > >> > >> Some macros that would be completely phased out, > in favor of platform > >> and policy decisions: > >> > >> PLATFORM(MAC) - A mix of things that should be > USE(APPKIT), > >> USE(NSURL_NET), ENABLE(OBJC_MAC_API) and a host of > other things > >> PLATFORM(WIN) - Hodgepodge of mandatory platform > adaptation, optional > >> platform adaptation, and choices specific to > Apple's Mac Port > >> PLATFORM(GTK) - Most of this would be replaced by > USE(GTK) but perhaps > >> different policy macros are appropriate in some > cases. > >> PLATFORM(CHROMIUM) - Grab-bag of various policy > choices. > >> > >> > >> I believe that with this new proposal, ifdefs in > the code would be > >> much more understandable. Any time something is > ifdef'd, it would be > >> clear why - is this to support a given public API? > Is it to support a > >> particular feature or variant behavior? Is it to > make use of an > >> underlying library? Is it just something you > *have* to do on the OS? > >> As a side effect, it would somewhat discourage > scattered trivial > >> behavior differences, since it would be necessary > to name and explain > >> them instead of just putting them behind a > catchall ifdef. I believe > >> every porter has been an offender on this front, > Apple included, and > >> it's probably best to minimize this sort of > thing. > >> > >> > >> This is not a new policy yet. Right now I am just > proposing it for > >> discussion. Thoughts? > >> > >> > >> Regards, > >> Maciej > >> > >> _______________________________________________ > >> webkit-dev mailing list > >> webkit-dev@lists.webkit.org > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev