Note: There are a few cases of duplicates in user autocompletion which are being worked on.

xpcom: AURORA_BASE_20110927 fails to build darwin/x11

RESOLVED FIXED in mozilla10

Status

()

Core
XPCOM
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Jeremy Huddleston, Assigned: Hanspeter Niederstrasser)

Tracking

Trunk
mozilla10
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
6dc468c41136 (20110820) built fine, but the AURORA_BASE_20110927 tag fails with various issues in xpcom (probably because someone assumed darwin == cocoa):

In file included from ./nsLocalFile.h:76:
./nsLocalFileUnix.h:57:10: fatal error: 'nsILocalFileMac.h' file not found
#include "nsILocalFileMac.h"
         ^

/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_www_firefox-x11-devel/firefox-x11-devel/work/mozilla-central/xpcom/io/nsAppFileLocationProvider.cpp:600:12: error: unknown type name 'SInt32'
    static SInt32 version = 0;
           ^
/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_www_firefox-x11-devel/firefox-x11-devel/work/mozilla-central/xpcom/io/nsAppFileLocationProvider.cpp:603:9: error: use of undeclared identifier 'OSErr'
        OSErr err = ::Gestalt(gestaltSystemVersion, &version);
        ^
(Reporter)

Comment 1

6 years ago
Created attachment 564034 [details] [diff] [review]
build fix for xpcom
(Reporter)

Updated

6 years ago
Summary: AURORA_BASE_20110927 fails to build darwin/x11 → xpcom: AURORA_BASE_20110927 fails to build darwin/x11

Updated

6 years ago
Attachment #564034 - Flags: review?(joshmoz)
(Assignee)

Comment 2

6 years ago
Created attachment 564544 [details] [diff] [review]
xpcom patch for m-c
Attachment #564544 - Flags: review?
(Assignee)

Comment 3

6 years ago
Comment on attachment 564544 [details] [diff] [review]
xpcom patch for m-c

grrr.  Anyway, here's the same patch modified to go cleanly against m-c.  Patching cleanly vs aurora got caught in the recent PRBool to bool transition.

I had previously tried to fix build failure this by changing xpcom/io/Makefile.in to generate nsILocalFileMac.h on Darwin (not just Cocoa), but that led me to a massive amount of patching then needed in the ipc area.  I'm not very clear in to what nsILocalFileMac.h ends up completely providing so I can't guess as to which method is better.  The patch below is several weeks old for reference.

diff --git a/xpcom/io/Makefile.in b/xpcom/io/Makefile.in
--- a/xpcom/io/Makefile.in
+++ b/xpcom/io/Makefile.in
@@ -152,19 +152,19 @@ XPIDLSRCS	= \
 		nsIIOUtil.idl \
 		nsISafeOutputStream.idl \
 		nsIScriptableBase64Encoder.idl \
 		$(NULL)
 
 ifeq ($(MOZ_WIDGET_TOOLKIT),os2)
 XPIDLSRCS	+= nsILocalFileOS2.idl
 else
-ifeq ($(MOZ_WIDGET_TOOLKIT),cocoa)
+ifeq ($(OS_ARCH),Darwin)
 XPIDLSRCS	+= nsILocalFileMac.idl
-endif # cocoa
+endif # Darwin
 endif # os2
 
 SDK_XPIDLSRCS   = \
 		nsIDirectoryService.idl \
 		nsIFile.idl \
 		nsILocalFile.idl \
 		nsIInputStream.idl \
 		nsIOutputStream.idl \
Attachment #564544 - Flags: review? → review?(joshmoz)

Updated

6 years ago
Attachment #564034 - Flags: review?(joshmoz) → review?(smichaud)

Updated

6 years ago
Attachment #564544 - Flags: review?(joshmoz) → review?(smichaud)
Comment on attachment 564034 [details] [diff] [review]
build fix for xpcom

As best I can tell this patch is obsoleted by your later patch.
Attachment #564034 - Flags: review?(smichaud)
Attachment #564034 - Attachment is obsolete: true
Comment on attachment 564544 [details] [diff] [review]
xpcom patch for m-c

I can't figure out why you need this patch:  As best I can tell XP_MACOSX and MOZ_WIDGET_COCOA are synonyms -- I can't figure out how one would get set without the other.  I suspect you've made other changes to the Mozilla build environment that you haven't told us about.

That said, I haven't tried to build on Darwin (as opposed to OS X), so I can't be 100% sure this patch isn't needed.  And in any case I'm quite sure it's harmless.  So I'm willing to r+ it.
Attachment #564544 - Flags: review?(smichaud) → review+
(Reporter)

Comment 6

6 years ago
MOZ_WIDGET_COCOA is for building against the Cocoa frameworks.

XP_MACOSX is for building on darwin (which can be Cocoa, GTK, ...)
> MOZ_WIDGET_COCOA is for building against the Cocoa frameworks.
>
> XP_MACOSX is for building on darwin (which can be Cocoa, GTK, ...)

OK, that makes sense as	a description of how these *should* be used.

But I still can't figure out how, without making any changes to
current trunk code, there could ever be a build environment in which
one of these would be set without the other being set.
Take a look at the top level configure.in (where both of these are set or not set) and see what you think.
(Assignee)

Comment 9

6 years ago
--enable-default-toolkit=cairo-gtk2 on Darwin (or even normal OS X) sets XP_MACOSX but not MOZ_WIDGET_COCOA.  Picking cairo-qt would have the same effect.
OK, yes.  I was assuming that you weren't explicitly doing anything to change either of these settings.  And I (now) can see why someone might want to cairo-gtk2 or cairo-qt on either Darwin or OS X.
> XP_MACOSX is for building on darwin (which can be Cocoa, GTK, ...)

Actually, since there's also an XP_DARWIN that can be defined in configure.in, XP_MACOSX should probably be for building on "normal" OS X.
>> XP_MACOSX is for building on darwin (which can be Cocoa, GTK, ...)
>
> Actually, since there's also an XP_DARWIN that can be defined in
> configure.in, XP_MACOSX should probably be for building on "normal"
> OS X.

But the actual use of XP_DARWIN in the tree seems to be as a superset
of XP_MACOSX and XP_IOS.
In any case, I can now better understand the reason for your patch.  It's not just harmless, it actually makes sense.
http://hg.mozilla.org/integration/mozilla-inbound/rev/124239b3d717
Assignee: nobody → niederstrasser
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/124239b3d717
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in before you can comment on or make changes to this bug.