Another aspect of this proposal is how to handle source files that have #if
ENABLE(FEATURE)/#endif guards around all of their source code, for example:
Bug 25756: Explicit guards for ENABLE_GEOLOCATION
https://bugs.webkit.org/show_bug.cgi?id=25756
There are essentially two options here:
1. Add #if/#endif guards to entire source files, but include every file in
every build system.
2. Make each build system smart enough to exclude source files that implement a
feature, thus pushing the policy decision down (up?) into the build system
(which is where most of the decisions are made today anyway).
I think #2 is a much cleaner way to handle this since it removes clutter from
the code (at the cost of duplicating knowledge of which files go with with
features into each build system).
Does anyone else have an opinion on this?
Dave
From: Maciej Stachowiak
To: WebKit Development
Sent: Thursday, April 30, 2009 4:12:54 PM
Subject: [webkit-dev] Proposal for a new way to handle porting #ifdefs
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
