Update Mac packaging to work without platypus #18522

simonbyrne · 2016-09-15T13:53:43Z

simonbyrne · 2016-09-15T13:54:06Z

simonbyrne · 2016-09-15T14:00:03Z

contrib/mac/app/Makefile

+	-mkdir -p $@/Contents/Resources/julia
+	make -C $(JULIAHOME) binary-dist
+	tar zxf ../../../julia-*.tar.gz -C $@/Contents/Resources/julia --strip-components 1
+	rm -f $@/Contents/Resources/julia/lib/*.{a,la}


Can we get rid of this line?

@ViralBShah this was your contribution: is this still necessary? Do we still build .a or .la files?

they get built by deps and we don't want to install them

ok, I didn't see any in my build, that's why I was wondering.

~~oh there might not be any under lib/julia at the moment~~ misread

I don't think this line is necessary anymore. I recently checked and noticed that we do not install the .a files.

I misread that path initially, but yeah we should be removing static libs and libtool junk during make install and/or make binary-dist which is before it gets here

simonbyrne · 2016-09-15T14:00:19Z

I've also gotten rid of some of the old cruft (like references to Winston and Cairo).

slarew · 2016-09-15T15:02:53Z

@simonbyrne I'll look over this tonight when I have some free time.

slarew · 2016-09-15T18:44:01Z

contrib/mac/app/Makefile

+	cp julia.icns $@/Contents/Resources/
+	plutil -replace CFBundleName -string "Julia" $@/Contents/Info.plist
+	plutil -replace CFBundleIconFile -string "julia.icns" $@/Contents/Info.plist
+	plutil -insert  CFBundleVersion -string "$(JULIA_VERSION_OPT_COMMIT)" $@/Contents/Info.plist


CFBundleVersion: "build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero—for example, 3.1.2" ... "While developing a new version of your app, you can include a suffix after the number that is being updated; for example 3.1.3a1"

I believe the JULIA_VERSION_OPT_COMMIT variable does not always precisely follow these rules. Maybe it doesn't matter too much in the case of nightlies which are not tagged commits.

It should always be of the form X.Y.Z, X.Y.Z-aaa or X.Y.Z-aaa-hash. At the moment the first integer is zero, but there's not much we can do about that.

For reference, platypus would use X.Y.Z or X.Y.Z-aaa.

slarew

I haven't tried this out, but the changes look good to me. I didn't know that osacompile could output an app bundle! That simplifies it all greatly.

Might consider making sure all the recommended Info.plist keys are added.

slarew · 2016-09-15T18:48:24Z

contrib/mac/app/Makefile

+	plutil -replace CFBundleName -string "Julia" $@/Contents/Info.plist
+	plutil -replace CFBundleIconFile -string "julia.icns" $@/Contents/Info.plist
+	plutil -insert  CFBundleVersion -string "$(JULIA_VERSION_OPT_COMMIT)" $@/Contents/Info.plist
+	plutil -insert  CFBundleShortVersionString -string "$(JULIA_VERSION)" $@/Contents/Info.plist


For release versions (e.g. 0.5.0), JULIA_VERSION is probably fine for CFBundleShortVersionString, which should just be three period separated integers. Not sure how important it is to strictly adhere to docs.

Me either. It will be of that form for release versions, but for nightlies it can be 0.5.0-dev

This should be fixed now.

slarew · 2016-09-15T18:56:18Z

contrib/mac/app/Makefile

+	plutil -replace CFBundleIconFile -string "julia.icns" $@/Contents/Info.plist
+	plutil -insert  CFBundleVersion -string "$(JULIA_VERSION_OPT_COMMIT)" $@/Contents/Info.plist
+	plutil -insert  CFBundleShortVersionString -string "$(JULIA_VERSION)" $@/Contents/Info.plist
+	plutil -insert  CFBundleIdentifier -string "org.julialang.julia" $@/Contents/Info.plist


This app identifier might be too generic. The prefix org.julialang is good. But the suffix of .julia is too generic. I would suggest something like org.julialang.julia.terminallauncherapp.

There are two related issues I'm thinking of here.

Bundle/app identifiers should be unique across the system. Suppose later on there are multiple apps published that all related to Julia in some way. Maybe one app just launches Terminal and the repl like we have here. But another app launches a native Cocoa repl with inline graphics support. Both apps need a unique bundle ID. So it doesn't hurt to be specific with the bundle ID in order to leave future changes/growth open.

Code signing ties the bundle/app ID to the code signature. And code signing really wants unique code signing IDs.

I'd suggest changing the app id to something more specific now while the app doesn't do anything of substance than have to deal with chaning the app id in the future when it could be more difficult.

I had just recently changed it for this reason (it used to be just org.julialang), but we can be more specific here.

Does this mean that we can't later switch the code signer for the same ID?

AFAIK, as of now, there are two points where the code signature comes into play:

GateKeeper checks the identity of the signer, which by default must be Apple or a registered Developer ID. If the signing identity doesn't pass GateKeeper checks, the code isn't allowed to execute. So as long as the signing identity is a Developer ID or Apple, it can be changed in the future without affecting the default behavior.

The macOS application (network) firewall records its rules base on the code signature. I have not tested this, but I think that if the signing identity changes, then the firewall rules may need to be updated. This is probably not a big deal.

slarew · 2016-09-15T18:57:52Z

contrib/mac/app/Makefile

+	plutil -insert  CFBundleVersion -string "$(JULIA_VERSION_OPT_COMMIT)" $@/Contents/Info.plist
+	plutil -insert  CFBundleShortVersionString -string "$(JULIA_VERSION)" $@/Contents/Info.plist
+	plutil -insert  CFBundleIdentifier -string "org.julialang.julia" $@/Contents/Info.plist
+	plutil -insert  NSHumanReadableCopyright -string "© 2016 The Julia Project" $@/Contents/Info.plist


Nitpicking: Most NSHumanReadableCopyright statements I see begin with the actual word "copyright" including the default one Xcode generates.

IANAL, but I think I read once that international copyright conventions/rules stipulate that the word "copyright" must be used. Of course, maybe I have it backwards...

Nevermind, Wikipedia says just using the symbol should be fine.

slarew · 2016-09-15T18:59:26Z

contrib/mac/app/Makefile


 all: clean $(DMG_NAME)

 $(DMG_NAME): dmg/$(APP_NAME)
 	-cp -f julia.icns dmg/.VolumeIcon.icns
 	-ln -fs /Applications ./dmg/Applications
-	-chmod 755 ./dmg/$(APP_NAME)/Contents/MacOS/Julia
+	-chmod 755 $</Contents/MacOS/applet


I would expect osacompile to set the permissions on the applet correctly. Is this necessary?

I don't think so. The background for this is #9010, and as I said in that issue it's a pretty weird edge case which most apps don't bother with. Maybe we should take this opportunity to get rid of it.

I say we see if we can get rid of it as we iterate on this PR. I'd like to simplify as much as possible, and the spirit of #9010 was the chown on line 30 anyway.

I've removed this now.

slarew · 2016-09-15T19:00:40Z

contrib/mac/app/README.md

@@ -0,0 +1,16 @@
+Julia OS X packaging


OS X -> macOS

Technically it's still OS X up to Sierra, which is still unreleased

I wonder if Apple provides official marketing guidelines on the OS X vs macOS naming issue.

slarew · 2016-09-15T19:02:32Z

contrib/mac/app/Makefile

+	plutil -insert  NSHumanReadableCopyright -string "© 2016 The Julia Project" $@/Contents/Info.plist
+	-mkdir -p $@/Contents/Resources/julia
+	make -C $(JULIAHOME) binary-dist
+	tar zxf ../../../julia-*.tar.gz -C $@/Contents/Resources/julia --strip-components 1


I believe strict adherence to code signing rules would disallow putting executable code (e.g. julia executable and deps libraries) in the Resources directory. But this is a whole different issue...

According to the updated Resource Rules, it looks like all files are signed, there is no distinction made between "Resources" and "Binaries" anymore, so the "security" side of this distinction should now be moot.

As far as adherence to protocol goes, Apple states:

...putting code into other places will cause it to be sealed as data (resource) files. This causes this code to be sealed twice; once in the nested code, and once in the outer signature. This wastes both signing and verification time and storage space. Also, this can break the outer signature of apps that use their own update mechanisms to replace nested code. If this nested code is being treated as resources, the outer signature doesn't know that this nested content is actually code.

Always put code and data into their proper places. This applies to all signed code and is enforced by the code signing machinery regardless of how the code is distributed.

They don't threaten us with codesigning breaking if we don't follow the rules, but they do say that the Mac App Store may reject submissions that don't follow these rules without warning:

Note: While strict compliance with these rules may not affect your app today, anything that doesn't meet these requirements note may be rejected by code signing verification (and the Mac App Store validator, in the case of Mac App Store apps) at any point in the future without notice.

All this being said, I'm not at all against moving things around, so if you have a better layout in mind I'd love to hear it. We can move things around pretty flexibly now by setting make flags such as these to place our binaries in the proper location, and our non-binaries in others.

The existing structure is just the same as what we did with platypus, but there's no real reason we can't change it. As a first step, it would probably make sense to structure it as a app-local framework.

I don't think we need to move individual files around though. The R and Python frameworks both just keep the usual unix directory structure buried somewhere, and then symlink everything as necessary.

That said, maybe this would be better as a different pull request.

tkelman · 2016-09-16T05:26:08Z

contrib/mac/app/Makefile

-	make -C ../../.. binary-dist
-	tar zxf ../../../julia-*.tar.gz
-	mv julia-* julia
-	-mkdir -p ./julia/libexec ./julia/share


are these created in the tarball now?

They seem to be. Also, I think these were leftover from the days when we included Tk and Cairo libs.

simonbyrne · 2016-09-16T11:29:16Z

I'm fairly happy with this now. I think we can leave the framework structure for another issue.

staticfloat · 2016-09-17T05:53:12Z

I'm running the tip of this branch through the buildbots to see what it comes up with.

staticfloat · 2016-09-17T06:41:57Z

Looks to work just fine, here's the resultant binary, grab it while it's hot!

ViralBShah · 2016-09-18T13:25:36Z

Binary seems to work well.

tkelman · 2016-09-20T04:23:58Z

Will this change the internal structure of the dmg in any way that we'd need to worry about on Travis for language: julia?

staticfloat · 2016-09-20T04:37:13Z

It shouldn't, from what I can tell.

simonbyrne · 2016-09-20T06:45:45Z

It shouldn't, I intentionally kept the directory structure the same.

simonbyrne · 2016-09-25T09:36:16Z

@tkelman I'll leave this up to you to pull the trigger on.

tkelman · 2016-09-25T12:40:05Z

I don't use or care about supporting this OS, but ok.

ViralBShah · 2016-09-25T13:22:44Z

Should we backport to 0.5?

simonbyrne · 2016-09-25T13:27:04Z

We can do, as it should be pretty much identical for users, but I'll leave this call to the release maintainers.

tkelman · 2016-09-26T02:17:40Z

if it doesn't cause any issues on the nightlies, it would be good for future-proofing to avoid accidentally upgrading to broken versions of things and releasing broken builds again

(cherry picked from commit 329e7e1) ref #18522 include fix for #14427 (cherry picked from commit 259e174) expand README (cherry picked from commit 399710e) remove use of sudo from OS X app makefile (cherry picked from commit 55fa673) add recommended Info.plist keys (cherry picked from commit aeadb11)

Update Mac packaging to work without platypus

329e7e1

simonbyrne added the system:mac Affects only macOS label Sep 15, 2016

simonbyrne commented Sep 15, 2016

View reviewed changes

simonbyrne added 2 commits September 15, 2016 15:06

include fix for #14427

259e174

expand README

399710e

simonbyrne mentioned this pull request Sep 15, 2016

RFC: Distribute an OS X Installer #15748

Closed

slarew reviewed Sep 15, 2016

View reviewed changes

ViralBShah added the building Build system, or building Julia or its dependencies label Sep 15, 2016

tkelman reviewed Sep 16, 2016

View reviewed changes

simonbyrne added 2 commits September 16, 2016 10:40

remove use of sudo from OS X app makefile

55fa673

add recommended Info.plist keys

aeadb11

staticfloat approved these changes Sep 17, 2016

View reviewed changes

slarew mentioned this pull request Sep 20, 2016

The 0.4.7 OS X .app is "damaged or incomplete" #18592

Closed

tkelman mentioned this pull request Sep 20, 2016

RFC: Add Darwin framework target #18594

Merged

tkelman merged commit e665592 into master Sep 25, 2016

tkelman deleted the sb/no-monotremes branch September 25, 2016 12:40

ViralBShah added the backport pending 0.5 label Sep 25, 2016

ViralBShah added this to the 0.5.x milestone Sep 25, 2016

simonbyrne mentioned this pull request Sep 28, 2016

OSAScript launch commands in OS X .dmg can behave incorrectly if user has a Parallels VM with a terminal open #14427

Closed

tkelman removed the backport pending 0.5 label Mar 5, 2017

vtjnash mentioned this pull request Jun 19, 2019

Open Julia in iTerm rather than Terminal if iTerm's installed #24906

Closed

Update Mac packaging to work without platypus #18522

Update Mac packaging to work without platypus #18522

Conversation

simonbyrne commented Sep 15, 2016

simonbyrne commented Sep 15, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkelman Sep 15, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonbyrne commented Sep 15, 2016 • edited Loading

slarew commented Sep 15, 2016

slarew Sep 15, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slarew left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slarew Sep 15, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

simonbyrne commented Sep 16, 2016

staticfloat commented Sep 17, 2016

staticfloat commented Sep 17, 2016

ViralBShah commented Sep 18, 2016

tkelman commented Sep 20, 2016

staticfloat commented Sep 20, 2016

simonbyrne commented Sep 20, 2016

simonbyrne commented Sep 25, 2016

tkelman commented Sep 25, 2016

ViralBShah commented Sep 25, 2016

simonbyrne commented Sep 25, 2016

tkelman commented Sep 26, 2016

tkelman Sep 15, 2016 •

edited

Loading

simonbyrne commented Sep 15, 2016 •

edited

Loading

slarew Sep 15, 2016 •

edited

Loading

slarew Sep 15, 2016 •

edited

Loading