emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: #defines and MacOS X


From: YAMAMOTO Mitsuharu
Subject: Re: #defines and MacOS X
Date: Fri, 28 Oct 2005 11:28:43 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Thu, 27 Oct 2005 13:18:31 -0400, Adrian Robert <address@hidden> said:

> One issue that comes up is #ifdef constant naming semantics, because
> the both ports have historically assumed they are the only windowing
> system port on the Mac, and therefore used constants like "MAC_OS"
> to delineate their code.

I'm not sure it is a good time to change them for Emacs 22, but their
convention is actually inconsistent.

> In particular, the Carbon port uses:

I think there are some misunderstandings in this part.

First, Mac OS Classic has Carbon and non-Carbon ports.  The Carbon
port is almost a superset of the non-Carbon one, but emulation of
synchronous processes is not available on the former.  Mac OS X
currently has terminal-only, X11, and Carbon ports.  Let me clarify
the current situation using them.

> MAC_OS
> - sometimes relevant to all MacOS, but sometimes just relevant to the  
> Carbon port on 8/9 and X

Classic/Carbon || Classic/non-Carbon || OSX/Carbon

> MAC_OSX
> - sometimes relevant to Darwin and/or OS X, but sometimes just  
> relevant to Carbon on OS X

OSX/terminal || OSX/X11 || OSX/Carbon
(Bare Darwin is not included.)

> TARGET_API_MAC_CARBON
>   - relevant to Carbon port on OS X only

Classic/Carbon || OSX/Carbon
(It is automatically set when Carbon.h or Carbon/Carbon.h is
included.)

> USE_CARBON_EVENTS
>   - pertaining to historical use of differing event mechanisms in  
> Carbon on OS X

I think it can be eliminated now (i.e., so that TARGET_API_MAC_CARBON
always assumes USE_CARBON_EVENTS).

> I want to change the use of MAC_OS and MAC_OSX to indicate the  
> operating system, not the GUI API used on it.  Therefore, we would get:

> MAC_OS_8, MAC_OS_9
>   - non-graphical code relevant on MacOS 8/9

The current code does not distinguish Mac OS 8 from 9.  Maybe
MAC_OS_CLASSIC can be used here.

> DARWIN
>   - non-graphical code relevant on MacOS X, as well as other Darwin  
> BSD distributions

`DARWIN' should not be defined on Mac OS X because CoreFoundation.h
uses it to distinguish Mac OS X from bare Darwin.

> ---------

>      CLASSIC
>       - graphical code for MacOS 8/9 only

>      CARBON
>       - graphical code for MacOS X only

I think the word `CLASSIC' is too general.  And CLASSIC and CARBON are
not the concepts at the same layer.

What we'd like to distinguish is:

   - Between (Classic/Carbon or OSX/Carbon) and Classic/non-Carbon
   - Between OSX/Carbon and Classic/Carbon

I think they can be achieved using standard macros TARGET_API_MAC_OS8,
TARGET_API_MAC_OSX, and TARGET_API_MAC_CARBON.  (Note that they can
only be used on Classic/non-Carbon, Classic/Carbon and OSX/Carbon
after a relevant header file is included).

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]