Commit graph

6 commits

Author SHA1 Message Date
Cam Hutchison d3eed17856
build: Support arm64 and universal binaries for MacOS (#25460)
* build: Support ARM64 (cross)builds of fido2 et al

Add support for building/cross-building the fido2 libraries (cbor,
openssl and fido2), supporting ARM64 builds. This is done by adding the
appropriate flags to the library builds in `build-fido2-macos.sh` based
on the `C_ARCH` environment variable. If unset then the host
architecture is used. The `Makefile` defined `C_ARCH` based on the
`ARCH` variable, mapping it to an appropriate value for the C compiler.

Building the libraries should now be done through the new `build-fido2`
target, and getting the pkg-config path should be done with the
`print-fido2-pkg-path`. This is instead of calling the
`build-fido2-macos.sh` script directly as the `Makefile` takes care of
setting the `C_ARCH` environment variable appropriately.

* build: Add make target to install rust cross toolchain

Add the `rustup-set-target-toolchain` target to the Makefile to ensure
the right rust toolchain is installed for the version of Rust we use as
well as the target architecture we wish to generate code for, based on
the `ARCH` variable. This is intended to be used by CI jobs to ensure
they build with the correct toolchain.

* build: Support building MacOS packages for ARM64

Remove the restriction that allows only AMD64 packages to be built on
MacOS for the teleport and tsh packages. This is via the existing `-a`
flag to `build-package.sh` and a newly added `-a` flag to
`build-pkg-tsh.sh`.

This adds the architecture to the filename of the package to distinguish
the packages for different architectures.

Update the comments in the Makefile mentioning that `arch` is ignored.

build: add architecture to package names

* build: Build Teleport Connect with target architecture

When packaging Teleport Connect with electron-builder, pass an
architecture flag so that we can cross-build Teleport Connect. This will
allow us to build MacOS ARM64 binaries on the AMD64 runners.

Add the architecture to the `dmg` filename via the electron-builder
config, so that the filenames for different architectures don't clash.

* build: Copy Mac release artifacts to release directory

Copy the Mac release artifacts to a release artifact directory so that
the CI scripts do not have to. This makes it clearer what is and is not
a release artifact and puts the logic in the Makefile instead of the CI
yaml, so it can more easily be tested locally and to make it easier to
migrate to the next CI system.

This will also be useful for building universal binaries for Mac as the
CI system can put the architecture-specific binaries from a previous
workflow job into a common location.

We should look at copying all release artifacts for the other builds
(Linux tarballs and packages, etc) into this directory too. It may help
with unifying the GitHub Actions release workflows.

* build: Add MacOS universal builds

Add support for ARCH=universal on Darwin to produce universal (fat)
binaries from pre-built arm64 and amd64 binaries.

Packages (pkg) and disk images (dmg) for containing universal binaries
are named without an architecture in the filename, as that is the
current naming for the current AMD64-only releases. These universal ones
will replace those AMD64-only ones providing a single release artifact
working across architectures.

Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com>

* build: Do not clean before release-darwin

Remove the `clean` prerequisite from the `release-darwin-unsigned`
target as it is not needed when building on GitHub Actions, as it starts
with a fresh slate each run. We do not make releases manually so we
don't need to ensure a clean working directory there either.

Not doing a clean makes it easier to build a MacOS universal release as
it depends on the architecture-specific tarballs from a previous release
build. We would need to manually save the tarballs from the first
architecture release build as they would get deleted by the `clean` from
the second. So just stop cleaning as it is not needed.

---------

Co-authored-by: Grzegorz Zdunek <grzegorz.zdunek@goteleport.com>
2023-05-04 20:47:49 +00:00
Cam Hutchison af8fe6f57a
release: Update build for product signing (#23820)
Update the build scripts to properly set up the key for signing packages
using `productsign`, and parameterise the bundle ID for packages in the
packaging scripts.
2023-04-03 00:30:48 +00:00
Alan Parra 0f386f273b
Make tsh installer non relocatable and drop version from app (#15018)
This is a twofold change with the aim of reducing possible pains with the tsh
installer.

- Dropping the version number from "tsh.app" makes it more alike other apps
  (including Connect)
- Making the installer non-relocatable makes it easy to reason about (and
  ensures our postinstall script is correct!)

A relocatable installer will look for the app in places other the specified
install path, according to the bundle ID. This means that if the user moves or
renames the app, the installer will overwrite it no matter where it is. It also
means our path assumptions can be wrong.

Note that the installer itself is still numbered, so it won't break Houston or
change the downloads page.
2022-07-29 11:18:27 -03:00
Alan Parra c206824be1
Drop v from macOS tsh installer version number (#13896)
Drop the `v` from the tsh installer version number, which was inadvertently
changed by #12751. Makes the installer reappear as a download option in Houston.

Note that the final .app name still has the `v`. Ie:

* tsh-10.0.0-dev.pkg (installer)
* tsh-10.0.0-dev.pkg.sha256 (installer hash)
* tsh-v10.0.0-dev.app (Application package)
2022-06-28 14:21:30 +00:00
Roman Tkachenko 423c005c7d
Fix tsh package build (#13813) 2022-06-25 00:16:46 +00:00
Alan Parra 99ad5c59a4
Build macOS installer for tsh.app (#12751)
Changes how `make pkg-tsh` works so instead of building an installer for the
`tsh` binary, placed under `/usr/local/bin`, we install an app to
`/Applications/tsh-vXXX.app` and link its `tsh` binary to `/usr/local/bin`.

The app shell is necessary to distribute a provisioning profile along with the
signed/entitled/notarized binary. All of that is required for Touch ID to work.
Naked `tsh` binaries are unable to use Touch ID, even if built with the correct
build tags.

I've elected to split the logic from `build-package.sh` into a separate script -
it already does too much as-is. `build-pkg-tsh.sh` is more idiomatic, clears
additional `shellcheck` rules and is easier to dry-run.

#9160

* Build macOS installer for tsh.app
* Add resources to build the tshdev app
Moved from e/

* Add resources to build the tsh app (prod)
* Use production values
* Remove 'tsh' mode from build-package.tsh
* Appease buildbox linter
* Clarify one-time setup
2022-05-23 20:56:21 +00:00