#defines and MacOS X

#defines and MacOS X

[Adrian Robert]

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

Re: #defines and MacOS X

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 27 Oct 2005 13:18:31 -0400, Adrian Robert <arobert@cogsci.ucsd.edu> 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
				mituharu@math.s.chiba-u.ac.jp

Re: #defines and MacOS X

[Adrian Robert]

On Oct 27, 2005, at 10:28 PM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Thu, 27 Oct 2005 13:18:31 -0400, Adrian Robert  
>>>>>> <arobert@cogsci.ucsd.edu> 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.

It can wait if that's what people prefer.  It doesn't make sense to  
do it on unicode-2 and not head due to hindering merging as mentioned  
in another message.  Also, I'm beginning to think (see below) perhaps  
someone more familiar with the Mac code than I should handle this,  
but I don't want to cause any delays of the 22 release.


>> 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.

I'm confused, because I thought "Carbon" referred to an API on OS X  
only that allowed OS 8/9 apps to be recompiled (with small  
modifications) and run on OS X.  Thus, I had been thinking the  
following were the only three cases:

- Mac running OS 8/9 w/o OS X installed -- "Classic non-Carbon"?
- Mac running app in "classic" emulation mode on OS X -- still  
"Classic non-Carbon"?
- Mac running app on OS X w/o emulation -- "Carbon"?

But I guess I'm wrong.  Which of these correspondences are right?   
And what machine does a "Classic Carbon" app run on?


>> 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.

There are a number of cases in the code currently where MAC_OS8 is  
checked for.  Are you saying Mac OS 8 AND 9 both define this, but  
Carbon on OS X doesn't?


>> 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.

OK, that's unfortunate.  In emacs, it's a little confusing since the  
MacOSX ports use 's/darwin.h'.  (What do the 8/9 ports use, BTW?)   
It's not a big deal, but maybe at some point s/macosx.h should be  
created (inheriting from darwin.h, or maybe bsd4-3.h), with a  
corresponding distinction in the 'SYSTEM_TYPE' variable.

Does GNU emacs support building on Darwin / non-MacOSX systems?


> 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).

I'll look into whether there are corresponding useful predefined  
constants in the Cocoa and GNUstep headers..

Re: #defines and MacOS X

[Kim F. Storm]

Adrian Robert <arobert@cogsci.ucsd.edu> writes:

> Meanwhile, I already updated the Nextstep port to avoid this problem
> using:
>
> HAVE_NS
>      GNUSTEP
>      COCOA

These should at least include MAC_ somewhere to 
indicate that they are specific to the MAC port, e.g

HAVE_MAC_NEXTSTEP
MAC_GNUSTEP
MAC_COCOA


> MAC_OS_8, MAC_OS_9
Ok

> DARWIN
Should be MAC_DARWIN

> MAC_TOOLBOX
Ok

>      CLASSIC
>      CARBON
>      HAVE_CARBON_EVENTS

Should be
MAC_CLASSIC
MAC_CARBON
HAVE_MAC_CARBON_EVENTS

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

Others will have to decide whether it is ok to do so now.

Personally, I think it should wait until after releasing 22.x -- also
on the unicode-2 branch to ease merging of patches between the branches.

Re: #defines and MacOS X

[Miles Bader]

2005/10/28, Kim F. Storm <storm@cua.dk>:
> > DARWIN
> Should be MAC_DARWIN

Darwin isn't mac-specific is it?  I thought that was the portion of
Mac OSX that Apple had made free...

-miles
--
Do not taunt Happy Fun Ball.

Re: #defines and MacOS X

[Kim F. Storm]

Miles Bader <snogglethorpe@gmail.com> writes:

> 2005/10/28, Kim F. Storm <storm@cua.dk>:
>> > DARWIN
>> Should be MAC_DARWIN
>
> Darwin isn't mac-specific is it?  I thought that was the portion of
> Mac OSX that Apple had made free...

I don't know ... but does emacs use it in non-MAC ports?
If not, it is mac specific in emacs context.

Otherwise, HAVE_DARWIN is better than DARWIN.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: #defines and MacOS X

[Adrian Robert]

On Oct 28, 2005, at 4:36 AM, Kim F. Storm wrote:

> Adrian Robert <arobert@cogsci.ucsd.edu> writes:
>
>
>> Meanwhile, I already updated the Nextstep port to avoid this problem
>> using:
>>
>> HAVE_NS
>>      GNUSTEP
>>      COCOA
>>
>
> These should at least include MAC_ somewhere to
> indicate that they are specific to the MAC port, e.g
>
> HAVE_MAC_NEXTSTEP
> MAC_GNUSTEP
> MAC_COCOA

Well, it's not "Mac" specific, since the same port runs on GNUstep  
(on linux, FreeBSD, eventually Windows, etc.).  The common  
denominator is the API, much like using Xlib on different OS's.  I  
thought briefly about:

HAVE_NS
NS_GNUSTEP
NS_COCOA

But then thought both GNUSTEP and COCOA were fairly clear in their  
own right.

The symbol 'ns' is used elsewhere for the port, as in window-system  
'ns, 'ns-win.el', etc..  I realize it may look a little short and  
cryptic, but given these are developer-visible strings, and every  
class and function name in the API starts with the letters "NS", it  
seems fairly clear.  Maybe another idea would be:

HAVE_NEXTSTEP (or perhaps HAVE_OPENSTEP)
NEXTSTEP_GNU
NEXTSTEP_MAC

Or HAVE_NEXTSTEP / NS_GNUSTEP / NS_COCOA...


>> Whatever is agreed upon, I'm willing to generate the patches for both
>> HEAD and the unicode-2 branch.
>>
>
> Others will have to decide whether it is ok to do so now.
>
> Personally, I think it should wait until after releasing 22.x -- also
> on the unicode-2 branch to ease merging of patches between the  
> branches.

I'm fine with this.  Especially if the Mac maintainers think that  
some logic (as opposed to just names) might change as a result, it's  
best to wait post-release.