Single app build for MacOS

[Jon Evans]

I discussed this with Adam a bit at KiCon -- we should investigate moving to a single app package on MacOS rather than a bundle with each KiCad tool as its own app inside the bundle.

This may be required for Apple notarization. It will also have side-effects of improving packaging time. We'll need to add some handling for file open targeting (drag and drop, etc) and provide command-line argument support for launching from the KiCad host into a single target application when the main KiCad (project manager) is not chosen to open by the user.

Somewhat related to lp:1753071

Setting as Wishlist for now but the priority might get bumped up if it turns out this is the only way to pass notarization by Apple.

[Wayne Stambaugh (stambaughw)]

What needs to be done to make this happen? I'm assuming at a minimum the gerber viewer, worksheet editor, calculator, and bitmap converter applications would have to be retooled to be child windows of KiCad instead of running in separate processes. To be honest, I'm not sure how this would fly. I know there are quite a few users who prefer to run Eeschema and Pcbnew as stand alone apps so I wouldn't see why this would be any different on macos. I'm not opposed to doing this but we should you the Kiway interface so we can keep them as separate apps on other platforms.

Is it possible that we are missing something with the macos signing that would allow us to use our current design? I don't pretend to know anything about macos (the gift that keeps on giving) so I'm just playing the devils advocate here. Maybe there is something we are over looking that would make our life easier.

[Seth Hillbrand (sethh)]

Can we add a copy of the notarization log file that is generated? This may provide more hints on the problem/how to resolve it.

[Adam Wolf (adamwolf)]

The problem with signing is that each .app gets signed, and they
clobber each others signatures--so while every file inside the bundle
is signed, they're not all signed for the same .app. (While things
can have multiple signatures, that's for things like signing a dmg and
the included apps, rather than the same file that is symlinked into
multiple .apps.) When you verify the signatures, it says there is a
signing mismatch--but there is no problem adding signatures. There
isn't really a log beyond "app signature mismatch". If you delete the
subapps, and just sign/verify kicad.app, it verifies fine. (The
problem with CMake is that it assumes that every file inside a bundle
belongs to that bundle, so when it processes each subapplication, it
messes with the rpaths so I have to add them back manually.)

Beyond signing, notarizing, CMake rpath issues, and Python build
complications, I actually forgot another complication we have because
of shared files via symlinks in our bundles--when you download KiCad
for macOS, you need to open KiCad.app before the standalone apps will
work. This is because of macOS quarantining not understanding
symlink-shared-files between different bundles. (We have this in the
README, but you know how often that gets opened :) )

I had talked about this with another developer a while ago, and then
at KiCon. We had brainstormed that KiCad.app would be a drop target
for all the file types, and would opens itself as the appropriate
standalone app if it's opening something that isn't a .pro file. If
you click on a .sch in the Finder, it would open KiCad.app with that
filetype, which would then tell KiCad.app to be eeschema.

Alternatively, we could work around this by just blowing up our
installer and skipping the symlinks. The point of the symlinks (today
at least, not 100% sure at creation time) is to save space by not
including files multiple times. Now that other parts of KiCad have
gotten larger, maybe everyone would be amenable to just including
multiple copies of each file.

Thoughts?

Adam Wolf

On Tue, Sep 10, 2019 at 1:41 PM Seth Hillbrand
<email address hidden> wrote:
>
> Can we add a copy of the notarization log file that is generated? This
> may provide more hints on the problem/how to resolve it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1826649
>
> Title:
> Single app build for MacOS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1826649/+subscriptions

[Jeff Young (jeyjey)]

Disk space is cheap. Besides, duplicating all the apps only increases our footprint by 6%.

[Adam Wolf (adamwolf)]

Ha! That's awesome. I'm going to migrate to that over the next few weeks, then.

I seem to remember it was saving like 30-50% of the download size, but
I don't even think we had 3D models back then...

On Tue, Sep 10, 2019 at 4:12 PM Jeff Young <email address hidden> wrote:
>
> Disk space is cheap. Besides, duplicating all the apps only increases
> our footprint by 6%.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1826649
>
> Title:
> Single app build for MacOS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1826649/+subscriptions

[Wayne Stambaugh (stambaughw)]

@Adam, does this mean that this bug report can be closed?

[Adam Wolf (adamwolf)]

It certainly shouldn't be worked on, but if the symlink-busting strategy
doesn't work for some reason, I'd like to reopen it. (I don't know
Launchpad very well, if closing lets us do that, then yesss!)

On Wed, Sep 11, 2019, 8:51 AM Wayne Stambaugh <email address hidden>
wrote:

> @Adam, does this mean that this bug report can be closed?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1826649
>
> Title:
> Single app build for MacOS
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1826649/+subscriptions
>

[Wayne Stambaugh (stambaughw)]

@Adam, I'll leave it open until the symlink-busting strategy is implemented. If it resolves the issues at hand, I will close this report at that time.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2396