emacs-devel
[Top][All Lists]
Advanced

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

#defines and MacOS X


From: Adrian Robert
Subject: #defines and MacOS X
Date: Thu, 27 Oct 2005 13:18:31 -0400

Hi,

I've been working on the Emacs.app GNUstep/Cocoa (Nextstep) port of Emacs, using the unicode-2 branch -- initial release expected in the next couple of weeks. 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.

In particular, the Carbon port uses:

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

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

TARGET_API_MAC_CARBON
 - relevant to Carbon port on OS X only

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


Meanwhile, I already updated the Nextstep port to avoid this problem using:

HAVE_NS
 - relevant to NeXTstep window system (on either GNUstep or OS X/Cocoa)

    GNUSTEP
     - relevant to GNUstep only

    COCOA
     - relevant to Cocoa / OS X only


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

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

MAC_OSX
 - non-graphical code relevant only on MacOS X

---------

MAC_TOOLBOX
 - code relevant to the Classic and Carbon ports on MacOS

    CLASSIC
     - graphical code for MacOS 8/9 only

    CARBON
     - graphical code for MacOS X only

    HAVE_CARBON_EVENTS
     - as before


Obviously there's more than one way to do this (using combinations, etc.), and I'm in no way wedded to the above proposal. If anyone has suggestions or preferences, please say so.

Whatever is agreed upon, I'm willing to generate the patches for both HEAD and the unicode-2 branch.

thanks,
Adrian





reply via email to

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