154232 - Turn off definition of DARWIN for Mach-0 build.

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Conrad Carlen (not reading bugmail)]

From review comment on bug 118203:

+  // XXX - Because we define DARWIN, we can't use CFURLGetFSRef. This blows.

file a bug for us to turn that off. we really should not be defining DARWIN when
building mozilla. as a workaround, can't you just #undef DARWIN at the top of
the file before including anything else? we do that in widget/src/cocoa all over
the place.

Comment 1

[hacker formerly known as [e-mail]]

Did I mention that Apple's use of that common, for obvious reasons, define in
their system headers is fairly boneheaded...on par with QT's past use of DEBUG
in their system headers?

The vast majority of the ifdefs that use that particular define in the Mozilla
tree come from NSPR, LDAP & NSS.  Since we still use platform defines on those
subsystems, we're going to need a define to replace DARWIN.

Comment 2

[David Haas (gone, not reading mail)]

Just a side note - I ran into this same dumb bug working
on Chimera.  Please make it go away.

Comment 3

[hacker formerly known as [e-mail]]

Attachment: Bye-bye DARWIN

Removed the silly DARWIN defines from the main Mozilla tree.  NSPR, NSS & LDAP
still use DARWIN to build as I don't see any reason why they shouldn't. 
However, I did remove the DARWIN (& XP_UNIX) define from
nsprpub/pr/src/md/include/_darwin.cfg because the defines bleeds into the
Mozilla build when the file is used as prcpucfg.h .

Comment 4

[Conrad Carlen (not reading bugmail)]

Nice, except

Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.1057
diff -u -r1.1057 configure.in
--- configure.in	2 Jul 2002 22:59:33 -0000	1.1057
+++ configure.in	8 Jul 2002 04:18:58 -0000
@@ -759,9 +759,6 @@
     ;;
 
 *-darwin*) 
-    AC_DEFINE(DARWIN)
-    AC_DEFINE(TARGET_CARBON)
-    AC_DEFINE(TARGET_API_MAC_CARBON)

I think we still need TARGET_CARBON.

Comment 5

[hacker formerly known as [e-mail]]

I was just cleaning out the redundant defines while I was there.  TARGET_CARBON
& TARGET_API_MAC_CARBON are also defined later in the ppc specific subsection.

Comment 6

[Wan-Teh Chang]

Comment on attachment 90456 [details] [diff] [review]
Bye-bye DARWIN

In nsprpub/pr/include/md/_darwin.cfg, the definitions
of the XP_UNIX and DARWIN macros are removed.

Should we define XP_DARWIN instead?

Does the definition of XP_UNIX cause problems elsewhere?
How do I indicate the fact that Darwin is a Unix flavor?

Comment 7

[hacker formerly known as [e-mail]]

> Should we define XP_DARWIN instead?

Actually, I had consider using PR_DARWIN so that it used the proper namespace.

> Does the definition of XP_UNIX cause problems elsewhere?
> How do I indicate the fact that Darwin is a Unix flavor?

XP_UNIX isn't causing a conflict afaik but I don't see why it's necessary to
define it there either.  

To whom are you trying to tell that Darwin is a unix flavor?  The defines in
_darwin.cfg are redundant when building NSPR as we already set XP_UNIX & DARWIN
in configure.in.  I would expect anyone that uses NSPR to have their own methods
for determining that Darwin was a unix variant or that they were using darwin at
all.  I wouldn't expect them to rely upon the defines in _<platform>.cfg.  If we
did set defines in those files, I would expect those defines to use a
non-generic namespace since they are being used in a public header file.

Comment 8

[Wan-Teh Chang]

Macros like XP_UNIX are being used by exported NSPR headers
such as prio.h.  It is a design goal of NSPR that NSPR clients
should not need to define any macro before including an NSPR
header.  This is why prcpucfg.h defines the macros needed by
exported NSPR headers.

The only problem is that some of the macros defined in
prcpucfg.h are not in the PR_ namespace.  Some use the
XP_ prefix; others don't have any prefix at all.  We should
leave the XP_UNIX macro definition in _darwin.cfg.

Although PR_DARWIN would be more correct, XP_DARWIN is more
consistent with the XP_BEOS and XP_OS2 macros that we are
already using.

Comment 9

[hacker formerly known as [e-mail]]

Attachment: s/DARWIN/XP_DARWIN/ for NSPR

Comment 10

[Wan-Teh Chang]

Comment on attachment 90588 [details] [diff] [review]
s/DARWIN/XP_DARWIN/ for NSPR

r=wtc.

Questions.

1. In js/src/fdlibm/k_standard.c

> #include "fdlibm.h"
> 
> /* XXX ugly hack to get msvc to link without error. */
>-#if _LIB_VERSION == _IEEE_ && !defined(DARWIN)
>+#if _LIB_VERSION == _IEEE_ && !(defined(DARWIN) || defined(XP_MACOSX))

Should this be just !defined(XP_MACOSX)?

2. It seems that you do not plan to have any code outside
NSPR (for example, NSS) use XP_DARWIN.	If that's the case,
perhaps we should remove the XP_DARWIN define from
nsprpub/pr/include/md/_darwin.cfg and only define XP_DARWIN
on the compile command line when we build NSPR.  We may even
have NSPR continue to use DARWIN internally.

Comment 11

[hacker formerly known as [e-mail]]

>>+#if _LIB_VERSION == _IEEE_ && !(defined(DARWIN) || defined(XP_MACOSX))
> 
> Should this be just !defined(XP_MACOSX)?

Nope.  In the standalone js build, they do not define XP_MACOSX but they do
define DARWIN.

> 2. It seems that you do not plan to have any code outside
> NSPR (for example, NSS) use XP_DARWIN.

Correct.  Mozilla doesn't rely upon NSPR to set the platform defines and we use
a separate define, XP_MACOSX, anyway.  So we're looking at something more along
the lines of the first patch with the XP_UNIX re-added.  Using DARWIN for NSPR
internally should be fine.  I'm unaware of any OSX specific headers that we use
in NSPR that would be crippled by using the define.

Comment 12

[hacker formerly known as [e-mail]]

Attachment: First patch w/o the XP_UNIX removal

Comment 13

[Wan-Teh Chang]

Comment on attachment 91441 [details] [diff] [review]
First patch w/o the XP_UNIX removal

r=wtc.

Comment 14

[Scott Collins]

Comment on attachment 91441 [details] [diff] [review]
First patch w/o the XP_UNIX removal

sr=scc

Comment 15

[Scott Collins]

Comment on attachment 91441 [details] [diff] [review]
First patch w/o the XP_UNIX removal

a=scc for checkin to the mozilla trunk

Comment 16

[hacker formerly known as [e-mail]]

Patch has been checked into the Mozilla trunk, NSPR trunk & the
NSPRPUB_PRE_4_2_CLIENT_BRANCH of NSPR.