This is untested beyond eyeballing the locally generated file.
Will need to make a couple of tags to test this for sure.
refs: https://github.com/wez/wezterm/issues/209
We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
This reverts commit 8dcf3cb21e.
My experience with even getting in the door with snaps was sub-par.
The submission/review process seems under specified and under staffed.
The tools for producing snaps were also rather broken in the case
that your PATH doesn't match a blessed configuration. This was
hard to discover and expensive to iterate on.
My conclusion is that snaps are not for me.
The icon comes from "Smoothicons 7" by Corey Marion which I found
as a royalty free icon searching the internet. I would love to
have a purpose built icon, but this is sufficient for now.
The install script sets up a macOS application bundle that references
the generated wezterm binary and the icon. The same technique could
be used to generate a .desktop file for linux.
I've changed the default-prog on macos to be `login -pf $USER` as
that is a better default experience on macOS.
