[Webkit-unassigned] [Bug 20890] Need to decouple building for the Mac from using NSURL/CFURL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20890





------- Comment #10 from mrowe at apple.com  2008-09-18 02:52 PDT -------
(In reply to comment #9)
> If the idea is to redefine MAC to an OS-level macro similar to WIN_OS, then it
> should probably be discussed on webkit-dev, as this affects other ports.

PLATFORM(MAC) is already a platform-level macro.  It indicates that we are
building against the Mac-level (CoreFoundation and above) frameworks on Mac OS
X.  PLATFORM(DARWIN) indicates that we're building against the BSD-level and
below APIs of Mac OS X.  

(In reply to comment #8)
> I once again question the idea of Chromium having PLATFORM(MAC) defined - the
> idea of MAC has always been "Apple's Mac port", and it shouldn't be defined
> when building Chromium, or Qt/Gtk ports on Mac OS X (the latter ports do adhere
> to this principle).

PLATFORM(MAC) doesn't indicate "Apple's Mac port".  We don't really have a
macro to indicate such a thing at this time.  Perhaps we need to introduce one?
 On Windows, for example, we indicate "Apple's Windows port" by the combination
of PLATFORM(WIN) and PLATFORM(CG).

The Qt and Gtk ports do not set PLATFORM(MAC) when building on Mac OS X as they
do not wish to use any of the Mac-level APIs even if they happen to be building
on Mac OS X.  The situation may be the same for Chromium, in which case they
may opt to leave PLATFORM(MAC) unset even if building on Mac OS X.  Otherwise,
if they wish to use Mac-level APIs, they should define PLATFORM(MAC) and we
should work out how to address any issues that arise from the code conflating
PLATFORM(MAC) with "Apple's Mac port".


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.