Closed Bug 933071 Opened 6 years ago Closed 6 years ago

require a --with-private-frameworks-path when cross-compiling for OS X

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla28

People

(Reporter: froydnj, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

We need this for libxul so we don't need /System/Library/PrivateFrameworks on the compile host machine; ideally we can inject it into webrtc too.
With this flag, I can get libxul to link.  The widget/cocoa changes are a drive-by, but
they appear totally unused in the current build configuration.
Attachment #825293 - Flags: review?(mshal)
Comment on attachment 825293 [details] [diff] [review]
add --with-macos-private-frameworks to support cross-compiling

This makes configure fail when run on Linux:

configure: error: PrivateFrameworks directory not found.
*** Fix above errors and then restart with               "make -f client.mk build"
make: *** [configure] Error 1

I guess it needs to go inside a check for OSX builds? Not sure the best way to do that.

Also I think you can do the default argument like this:

MOZ_ARG_WITH_STRING(macos-private-frameworks,
[  --with-macos-private-frameworks=dir    Location of private frameworks to use (Mac OS X only)],
    MACOS_PRIVATE_FRAMEWORKS_DIR=$withval,
    MACOS_PRIVATE_FRAMEWORKS_DIR=/System/Library/PrivateFrameworks)

So you don't need the _DEFAULT variable and such.
Attachment #825293 - Flags: review?(mshal) → feedback+
(In reply to Michael Shal [:mshal] from comment #2)
> Comment on attachment 825293 [details] [diff] [review]
> add --with-macos-private-frameworks to support cross-compiling
> 
> This makes configure fail when run on Linux:
> 
> configure: error: PrivateFrameworks directory not found.
> *** Fix above errors and then restart with               "make -f client.mk
> build"
> make: *** [configure] Error 1
> 
> I guess it needs to go inside a check for OSX builds? Not sure the best way
> to do that.

Oh, hm.  I guess maybe the checks should be guarded by whether we have a MacOS SDK to compile against.

> Also I think you can do the default argument like this:
> 
> MOZ_ARG_WITH_STRING(macos-private-frameworks,
> [  --with-macos-private-frameworks=dir    Location of private frameworks to
> use (Mac OS X only)],
>     MACOS_PRIVATE_FRAMEWORKS_DIR=$withval,
>     MACOS_PRIVATE_FRAMEWORKS_DIR=/System/Library/PrivateFrameworks)
> 
> So you don't need the _DEFAULT variable and such.

Mm, good to know!  I was keeping the _DEFAULT variable so configure could complain at people who set it to something weird and weren't cross-compiling.
Here's a revised version that seems to pass smoketesting on Linux.
Attachment #825293 - Attachment is obsolete: true
Attachment #825376 - Flags: review?(mshal)
Actually, let's fix the WebRTC case, too, since that's definitely under our control.
Attachment #825376 - Attachment is obsolete: true
Attachment #825376 - Flags: review?(mshal)
Attachment #825380 - Flags: review?(mshal)
Comment on attachment 825380 [details] [diff] [review]
add --with-macos-private-frameworks to support cross-compiling

This looks good to me now!
Attachment #825380 - Flags: review?(mshal) → review+
https://hg.mozilla.org/mozilla-central/rev/9c8d23cfa1d8
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.