Currently we package a XULRunner installer on mac which will install XULRunner to /Library/Frameworks/XUL.framework. This wasn't a good idea to begin with and we removed support for even searching in system locations a while back. We want application authors to package XULRunner in their individual application bundles. To that end, I have removed the installer generation code and am just going "back" to packaging a .tar.bz2 file.
Created attachment 605046 [details] [diff] [review]
Remove the installer, rev. 1
Comment on attachment 605046 [details] [diff] [review]
Remove the installer, rev. 1
Review of attachment 605046 [details] [diff] [review]:
This doesn't include the removals for xulrunner/installer/mac. Is that a mistake or intentional?
The readme looks good to me, I think as long as it links to the website then that should give everyone all the info they might want. Do we want to mention the license or is a LICENSE file already included somewhere?
Created attachment 605757 [details] [diff] [review]
Remove the installer, rev. 1.1
There is a separate LICENSE file. Not including the xulrunner/installer/mac removal in the patch was accidental. `hg rm` and `rm` aren't identical ;-)
This broke the universal build due to flight.mk referencing xulrunner/installer/mac: I'll work on fixing that tomorrow.
Created attachment 611093 [details] [diff] [review]
bustage fix WIP
This at least makes the build and package steps complete in universal builds. I haven't done any testing in non-UB or comparisons to what was generated before and after yet though.
Created attachment 612399 [details] [diff] [review]
I've run builds locally in both non-universal and universal and all succeed and package both XULRunner and the SDK ok. I didn't go so far as comparing the exact files included because of one complication, it turns out that we now omnijar XULRunner where we didn't when doing a pkg. A brief check shows all relevant files are present and I can run an application with the generated framework.
There were a bunch of problems with packaging here, mostly stemming from the fact that all of the support for packaging a bundle is ifdeffed behind a check for the package format being DMG. I suspect it doesn't need to be ifdeffed behind anything but to minimise the potential for breakage elsewhere I hid it behind toolkit=cocoa here.
I also made a slight change to where we tar file from so the tarball contains the XUL.framework directory directly (rather than xulrunner/XUL.framework).
Comment on attachment 612399 [details] [diff] [review]
Yeah, I got halfway through writing the same patch and got stuck! thanks for finishing this.
Landed on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/d36aeec1abe1
This is a pretty significant change for XULRunner app developers. The XULRunner docs could use some tender loving care, anyway...