* #defines and MacOS X
@ 2005-10-27 17:18 Adrian Robert
2005-10-28 2:28 ` YAMAMOTO Mitsuharu
2005-10-28 8:36 ` Kim F. Storm
0 siblings, 2 replies; 7+ messages in thread
From: Adrian Robert @ 2005-10-27 17:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #defines and MacOS X
2005-10-27 17:18 #defines and MacOS X Adrian Robert
@ 2005-10-28 2:28 ` YAMAMOTO Mitsuharu
2005-10-28 15:11 ` Adrian Robert
2005-10-28 8:36 ` Kim F. Storm
1 sibling, 1 reply; 7+ messages in thread
From: YAMAMOTO Mitsuharu @ 2005-10-28 2:28 UTC (permalink / raw)
Cc: emacs-devel
>>>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #defines and MacOS X
2005-10-28 2:28 ` YAMAMOTO Mitsuharu
@ 2005-10-28 15:11 ` Adrian Robert
0 siblings, 0 replies; 7+ messages in thread
From: Adrian Robert @ 2005-10-28 15:11 UTC (permalink / raw)
Cc: emacs-devel
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..
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #defines and MacOS X
2005-10-27 17:18 #defines and MacOS X Adrian Robert
2005-10-28 2:28 ` YAMAMOTO Mitsuharu
@ 2005-10-28 8:36 ` Kim F. Storm
2005-10-28 11:22 ` Miles Bader
2005-10-28 15:22 ` Adrian Robert
1 sibling, 2 replies; 7+ messages in thread
From: Kim F. Storm @ 2005-10-28 8:36 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #defines and MacOS X
2005-10-28 8:36 ` Kim F. Storm
@ 2005-10-28 11:22 ` Miles Bader
2005-10-28 11:48 ` Kim F. Storm
2005-10-28 15:22 ` Adrian Robert
1 sibling, 1 reply; 7+ messages in thread
From: Miles Bader @ 2005-10-28 11:22 UTC (permalink / raw)
Cc: Adrian Robert, emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #defines and MacOS X
2005-10-28 8:36 ` Kim F. Storm
2005-10-28 11:22 ` Miles Bader
@ 2005-10-28 15:22 ` Adrian Robert
1 sibling, 0 replies; 7+ messages in thread
From: Adrian Robert @ 2005-10-28 15:22 UTC (permalink / raw)
Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-10-28 15:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-27 17:18 #defines and MacOS X Adrian Robert
2005-10-28 2:28 ` YAMAMOTO Mitsuharu
2005-10-28 15:11 ` Adrian Robert
2005-10-28 8:36 ` Kim F. Storm
2005-10-28 11:22 ` Miles Bader
2005-10-28 11:48 ` Kim F. Storm
2005-10-28 15:22 ` Adrian Robert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).