status-desktop/Makefile

456 lines
15 KiB
Makefile
Raw Normal View History

2020-05-14 14:58:08 +00:00
# Copyright (c) 2019-2020 Status Research & Development GmbH. Licensed under
# either of:
# - Apache License, version 2.0
# - MIT license
# at your option. This file may not be copied, modified, or distributed except
# according to those terms.
2020-05-06 21:26:32 +00:00
2020-05-14 14:58:08 +00:00
SHELL := bash # the shell used internally by Make
2020-05-06 21:43:20 +00:00
2020-05-14 14:58:08 +00:00
# used inside the included makefiles
BUILD_SYSTEM_DIR := vendor/nimbus-build-system
# we don't want an error here, so we can handle things later, in the ".DEFAULT" target
-include $(BUILD_SYSTEM_DIR)/makefiles/variables.mk
.PHONY: \
all \
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
bottles \
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
check-pkg-target-linux \
check-pkg-target-macos \
check-pkg-target-windows \
2020-05-14 14:58:08 +00:00
clean \
deps \
fleets-remove \
fleets-update \
nim_status_client \
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
nim_windows_launcher \
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
pkg \
pkg-linux \
pkg-macos \
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
pkg-windows \
run \
run-linux \
run-macos \
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
run-windows \
set-status-macos-dev-icon \
status-go \
2020-05-14 14:58:08 +00:00
update
ifeq ($(NIM_PARAMS),)
# "variables.mk" was not included, so we update the submodules.
GIT_SUBMODULE_UPDATE := git submodule update --init --recursive
.DEFAULT:
+@ echo -e "Git submodules not found. Running '$(GIT_SUBMODULE_UPDATE)'.\n"; \
$(GIT_SUBMODULE_UPDATE); \
echo
# Now that the included *.mk files appeared, and are newer than this file, Make will restart itself:
# https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles
#
# After restarting, it will execute its original goal, so we don't have to start a child Make here
# with "$(MAKE) $(MAKECMDGOALS)". Isn't hidden control flow great?
else # "variables.mk" was included. Business as usual until the end of this file.
all: nim_status_client
# must be included after the default target
-include $(BUILD_SYSTEM_DIR)/makefiles/targets.mk
2020-05-14 14:58:08 +00:00
ifeq ($(OS),Windows_NT) # is Windows_NT on XP, 2000, 7, Vista, 10...
detected_OS := Windows
2020-05-14 14:58:08 +00:00
else
detected_OS := $(strip $(shell uname))
2020-05-14 14:58:08 +00:00
endif
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
ifeq ($(detected_OS),Darwin)
CFLAGS := -mmacosx-version-min=10.14
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
export CFLAGS
CGO_CFLAGS := -mmacosx-version-min=10.14
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
export CGO_CFLAGS
LIBSTATUS_EXT := dylib
MACOSX_DEPLOYMENT_TARGET := 10.14
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
export MACOSX_DEPLOYMENT_TARGET
PKG_TARGET := pkg-macos
RUN_TARGET := run-macos
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
else ifeq ($(detected_OS),Windows)
LIBSTATUS_EXT := dll
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
PKG_TARGET := pkg-windows
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
QRCODEGEN_MAKE_PARAMS := CC=gcc
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
RUN_TARGET := run-windows
build: implement code signing step for the Windows build Add a code signing step to the `pkg-windows` target. If the environment variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not set then a verified timestamp will not be included in the signature. Both variables should be set in production/CI builds. Signing is performed with Window's [SignTool][signtool]. There is a helpful [Stack Overflow answer][soa] which explains how to easily setup a self-signed CA and code signing certificate and then use them with `signtool`, which is how I tested these changes on my local Windows machine. Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally running other installations of those executables than the ones that ship with Git Bash. I was experiencing mysterious failures in the sequence of commands and then noticed that e.g. `which xargs` was resolving to an executable in `${HOME}/scoop/shims`. I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and Windows 10. For CI builds Status will need to acquire a signing certificate from e.g. DigiCert. There will be a yearly renewal cost. In researching what files should be signed, I concluded that it only makes sense to sign `.dll` and `.exe` files. It's possible to generate signatures for other file types but the signatures would have to be stored apart from those files, unlike `.dll` and `.exe` where the signature is embedded in the executable. Also, it doesn't seem to be possible to embed a signature in a `.zip` file, though it would be possible to sign the compressed package if we chose to build and distribute a self-extracting `Status.exe` instead of `Status.zip`. If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe sign` is not invoked on that file. Closes #288. [signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool [soa]: https://stackoverflow.com/a/201277
2020-07-21 16:28:42 +00:00
SIGNTOOL ?= C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.17763.0\\x64\\signtool.exe
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
VCINSTALLDIR ?= C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\VC\\
export VCINSTALLDIR
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
else
LIBSTATUS_EXT := so
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
PKG_TARGET := pkg-linux
RUN_TARGET := run-linux
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
endif
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
check-pkg-target-linux:
ifneq ($(detected_OS),Linux)
$(error The pkg-linux target must be run on Linux)
endif
check-pkg-target-macos:
ifneq ($(detected_OS),Darwin)
$(error The pkg-macos target must be run on macOS)
endif
check-pkg-target-windows:
ifneq ($(detected_OS),Windows)
$(error The pkg-windows target must be run on Windows)
endif
ifeq ($(detected_OS),Darwin)
bottles/openssl:
./scripts/fetch-brew-bottle.sh openssl
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
bottles/pcre:
./scripts/fetch-brew-bottle.sh pcre
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
bottles: bottles/openssl bottles/pcre
endif
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
deps: | deps-common bottles
2020-05-14 14:58:08 +00:00
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
update: | update-common
# Qt5 dirs (we can't indent with tabs here)
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
ifneq ($(detected_OS),Windows)
QT5_PCFILEDIR := $(shell pkg-config --variable=pcfiledir Qt5Core 2>/dev/null)
QT5_LIBDIR := $(shell pkg-config --variable=libdir Qt5Core 2>/dev/null)
ifeq ($(QT5_PCFILEDIR),)
ifeq ($(QTDIR),)
$(error Cannot find your Qt5 installation. Please run "$(MAKE) QTDIR=/path/to/your/Qt5/installation/prefix ...")
else
QT5_PCFILEDIR := $(QTDIR)/lib/pkgconfig
QT5_LIBDIR := $(QTDIR)/lib
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
# some manually installed Qt5 instances have wrong paths in their *.pc files, so we pass the right one to the linker here
ifeq ($(detected_OS),Darwin)
NIM_PARAMS += -L:"-framework Foundation -framework Security -framework IOKit -framework CoreServices"
# Fix for failures due to 'can't allocate code signature data for'
NIM_PARAMS += --passL:"-headerpad_max_install_names"
NIM_PARAMS += --passL:"-F$(QT5_LIBDIR)"
export QT5_LIBDIR
else
NIM_PARAMS += --passL:"-L$(QT5_LIBDIR)"
endif
endif
endif
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
DOTHERSIDE := vendor/DOtherSide/build/lib/libDOtherSideStatic.a
DOTHERSIDE_CMAKE_PARAMS := -DENABLE_DYNAMIC_LIBS=OFF -DENABLE_STATIC_LIBS=ON
DOTHERSIDE_BUILD_CMD := $(MAKE) VERBOSE=$(V) $(HANDLE_OUTPUT)
# order matters here, due to "-Wl,-as-needed"
NIM_PARAMS += --passL:"$(DOTHERSIDE)" --passL:"$(shell PKG_CONFIG_PATH="$(QT5_PCFILEDIR)" pkg-config --libs Qt5Core Qt5Qml Qt5Gui Qt5Quick Qt5QuickControls2 Qt5Widgets Qt5Svg)"
else
DOTHERSIDE := vendor/DOtherSide/build/lib/Release/DOtherSide.dll
DOTHERSIDE_CMAKE_PARAMS := -T"v141" -A x64 -DENABLE_DYNAMIC_LIBS=ON -DENABLE_STATIC_LIBS=OFF
DOTHERSIDE_BUILD_CMD := cmake --build . --config Release $(HANDLE_OUTPUT)
NIM_PARAMS += -L:$(DOTHERSIDE)
NIM_EXTRA_PARAMS := --passL:"-lsetupapi -lhid"
endif
2020-05-14 14:58:08 +00:00
# TODO: control debug/release builds with a Make var
# We need `-d:debug` to get Nim's default stack traces.
NIM_PARAMS += --outdir:./bin -d:debug
# Enable debugging symbols in DOtherSide, in case we need GDB backtraces from it.
CFLAGS += -g
CXXFLAGS += -g
2020-05-14 14:58:08 +00:00
$(DOTHERSIDE): | deps
echo -e $(BUILD_MSG) "DOtherSide"
+ cd vendor/DOtherSide && \
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
mkdir -p build && \
cd build && \
rm -f CMakeCache.txt && \
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
cmake $(DOTHERSIDE_CMAKE_PARAMS)\
-DCMAKE_BUILD_TYPE=Release \
-DENABLE_DOCS=OFF \
-DENABLE_TESTS=OFF \
.. $(HANDLE_OUTPUT) && \
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
$(DOTHERSIDE_BUILD_CMD)
2020-05-14 14:58:08 +00:00
STATUSGO := vendor/status-go/build/bin/libstatus.$(LIBSTATUS_EXT)
STATUSGO_LIBDIR := $(shell pwd)/$(shell dirname "$(STATUSGO)")
export STATUSGO_LIBDIR
2020-05-14 20:19:01 +00:00
status-go: $(STATUSGO)
2020-05-14 20:19:01 +00:00
$(STATUSGO): | deps
echo -e $(BUILD_MSG) "status-go"
+ cd vendor/status-go && \
$(MAKE) statusgo-shared-library $(HANDLE_OUTPUT)
2020-05-14 14:58:08 +00:00
2020-06-23 17:17:58 +00:00
QRCODEGEN := vendor/QR-Code-generator/c/libqrcodegen.a
$(QRCODEGEN): | deps
echo -e $(BUILD_MSG) "QR-Code-generator"
+ cd vendor/QR-Code-generator/c && \
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
$(MAKE) $(QRCODEGEN_MAKE_PARAMS)
2020-06-23 17:17:58 +00:00
FLEETS := fleets.json
$(FLEETS):
echo -e $(BUILD_MSG) "Getting latest $(FLEETS)"
curl -s https://fleets.status.im/ \
| jq --indent 4 --sort-keys . \
> $(FLEETS)
fleets-remove:
rm -f $(FLEETS)
2020-11-06 15:50:58 +00:00
fleets-update: fleets-remove $(FLEETS)
rcc:
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e $(BUILD_MSG) "resources.rcc"
rm -f ./resources.rcc
rm -f ./ui/resources.qrc
./ui/generate-rcc.sh
rcc -binary ui/resources.qrc -o ./resources.rcc
# default token is a free-tier token with limited capabilities and usage
# limits; our docs should include directions for community contributor to setup
# their own Infura account and token instead of relying on this default token
# during development
DEFAULT_TOKEN := 220a1abb4b6943a093c35d0ce4fb0732
INFURA_TOKEN ?= $(DEFAULT_TOKEN)
NIM_PARAMS += -d:INFURA_TOKEN:"$(INFURA_TOKEN)"
nim_status_client: | $(DOTHERSIDE) $(STATUSGO) $(QRCODEGEN) $(FLEETS) rcc deps
2020-05-14 14:58:08 +00:00
echo -e $(BUILD_MSG) "$@" && \
$(ENV_SCRIPT) nim c $(NIM_PARAMS) --passL:"-L$(STATUSGO_LIBDIR)" --passL:"-lstatus" $(NIM_EXTRA_PARAMS) --passL:"$(QRCODEGEN)" --passL:"-lm" src/nim_status_client.nim && \
[[ $$? = 0 ]] && \
(([[ $(detected_OS) = Darwin ]] && \
install_name_tool -change \
libstatus.dylib \
@rpath/libstatus.dylib \
bin/nim_status_client) || true)
2020-05-14 20:19:01 +00:00
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
_APPIMAGE_TOOL := appimagetool-x86_64.AppImage
APPIMAGE_TOOL := tmp/linux/tools/$(_APPIMAGE_TOOL)
$(APPIMAGE_TOOL):
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e "\e[92mFetching:\e[39m appimagetool"
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
rm -rf tmp/linux
mkdir -p tmp/linux/tools
wget https://github.com/AppImage/AppImageKit/releases/download/continuous/$(_APPIMAGE_TOOL)
mv $(_APPIMAGE_TOOL) tmp/linux/tools/
chmod +x $(APPIMAGE_TOOL)
2020-05-19 15:32:48 +00:00
STATUS_CLIENT_APPIMAGE ?= pkg/NimStatusClient-x86_64.AppImage
2020-05-14 20:19:01 +00:00
$(STATUS_CLIENT_APPIMAGE): nim_status_client $(APPIMAGE_TOOL) nim-status.desktop
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
rm -rf pkg/*.AppImage
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
rm -rf tmp/linux/dist
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
mkdir -p tmp/linux/dist/usr/bin
mkdir -p tmp/linux/dist/usr/lib
mkdir -p tmp/linux/dist/usr/qml
2020-05-15 13:00:49 +00:00
# General Files
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
cp bin/nim_status_client tmp/linux/dist/usr/bin
cp nim-status.desktop tmp/linux/dist/.
cp status.svg tmp/linux/dist/status.svg
cp status.svg tmp/linux/dist/usr/.
cp -R resources.rcc tmp/linux/dist/usr/.
cp -R $(FLEETS) tmp/linux/dist/usr/.
2020-08-10 20:19:15 +00:00
mkdir -p tmp/linux/dist/usr/i18n
cp ui/i18n/* tmp/linux/dist/usr/i18n
2020-05-15 13:00:49 +00:00
# Libraries
2020-10-07 15:24:24 +00:00
cp -r /usr/lib/x86_64-linux-gnu/nss tmp/linux/dist/usr/lib/
cp vendor/status-go/build/bin/libstatus.so tmp/linux/dist/usr/lib/
2020-05-14 20:19:01 +00:00
echo -e $(BUILD_MSG) "AppImage"
linuxdeployqt tmp/linux/dist/nim-status.desktop -no-copy-copyright-files -qmldir=ui -qmlimport=$(QTDIR)/qml -bundle-non-qt-libs
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
rm tmp/linux/dist/AppRun
cp AppRun tmp/linux/dist/.
mkdir -p pkg
$(APPIMAGE_TOOL) tmp/linux/dist $(STATUS_CLIENT_APPIMAGE)
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
DMG_TOOL := node_modules/.bin/create-dmg
2020-05-15 13:00:49 +00:00
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
$(DMG_TOOL):
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e "\e[92mInstalling:\e[39m create-dmg"
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
npm i
2020-05-15 13:00:49 +00:00
2020-09-22 15:12:48 +00:00
MACOS_OUTER_BUNDLE := tmp/macos/dist/Status.app
MACOS_INNER_BUNDLE := $(MACOS_OUTER_BUNDLE)/Contents/Frameworks/QtWebEngineCore.framework/Versions/Current/Helpers/QtWebEngineProcess.app
2020-05-14 20:19:01 +00:00
STATUS_CLIENT_DMG ?= pkg/Status.dmg
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
$(STATUS_CLIENT_DMG): nim_status_client $(DMG_TOOL)
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
rm -rf tmp/macos pkg/*.dmg
2020-09-22 15:12:48 +00:00
mkdir -p $(MACOS_OUTER_BUNDLE)/Contents/MacOS
mkdir -p $(MACOS_OUTER_BUNDLE)/Contents/Resources
cp Info.plist $(MACOS_OUTER_BUNDLE)/Contents/
cp bin/nim_status_client $(MACOS_OUTER_BUNDLE)/Contents/MacOS/
cp nim_status_client.sh $(MACOS_OUTER_BUNDLE)/Contents/MacOS/
chmod +x $(MACOS_OUTER_BUNDLE)/Contents/MacOS/nim_status_client.sh
cp status.icns $(MACOS_OUTER_BUNDLE)/Contents/Resources/
2020-09-22 15:12:48 +00:00
cp status.svg $(MACOS_OUTER_BUNDLE)/Contents/
cp -R resources.rcc $(MACOS_OUTER_BUNDLE)/Contents/
cp -R $(FLEETS) $(MACOS_OUTER_BUNDLE)/Contents/
2020-09-22 15:12:48 +00:00
mkdir -p $(MACOS_OUTER_BUNDLE)/Contents/i18n
cp ui/i18n/* $(MACOS_OUTER_BUNDLE)/Contents/i18n
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e $(BUILD_MSG) "app"
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
macdeployqt \
2020-09-22 15:12:48 +00:00
$(MACOS_OUTER_BUNDLE) \
-executable=$(MACOS_OUTER_BUNDLE)/Contents/MacOS/nim_status_client \
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
-qmldir=ui
2020-09-22 15:12:48 +00:00
cp Info.runner.plist $(MACOS_OUTER_BUNDLE)/Contents/Info.plist
macdeployqt \
$(MACOS_INNER_BUNDLE) \
-executable=$(MACOS_INNER_BUNDLE)/Contents/MacOS/QtWebEngineProcess
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
2020-09-22 15:12:48 +00:00
# if MACOS_CODESIGN_IDENT is not set then the outer and inner .app
# bundles are not signed
ifdef MACOS_CODESIGN_IDENT
2020-09-22 15:12:48 +00:00
scripts/sign-macos-pkg.sh $(MACOS_OUTER_BUNDLE) $(MACOS_CODESIGN_IDENT)
scripts/sign-macos-pkg.sh $(MACOS_INNER_BUNDLE) $(MACOS_CODESIGN_IDENT) \
--entitlements QtWebEngineProcess.plist
endif
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e $(BUILD_MSG) "dmg"
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
mkdir -p pkg
# See: https://github.com/sindresorhus/create-dmg#dmg-icon
# GraphicsMagick must be installed for create-dmg to make the custom
# DMG icon based on app icon, but should otherwise work without it
npx create-dmg \
--identity="NOBODY" \
2020-09-22 15:12:48 +00:00
$(MACOS_OUTER_BUNDLE) \
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
pkg || true
# We ignore failure above create-dmg can't skip signing.
# To work around that a dummy identity - 'NOBODY' - is specified.
# This causes non-zero exit code despite DMG being created.
# It is just not signed, hence the next command should succeed.
mv "`ls pkg/*.dmg`" $(STATUS_CLIENT_DMG)
ifdef MACOS_CODESIGN_IDENT
scripts/sign-macos-pkg.sh $(STATUS_CLIENT_DMG) $(MACOS_CODESIGN_IDENT)
endif
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
NIM_WINDOWS_PREBUILT_DLLS ?= tmp/windows/tools/pcre.dll
$(NIM_WINDOWS_PREBUILT_DLLS):
echo -e "\e[92mFetching:\e[39m prebuilt DLLs from nim-lang.org"
rm -rf tmp/windows
mkdir -p tmp/windows/tools
cd tmp/windows/tools && \
wget https://nim-lang.org/download/dlls.zip && \
unzip dlls.zip
nim_windows_launcher: | deps
$(ENV_SCRIPT) nim c -d:debug --outdir:./bin --passL:"-static-libgcc -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive" src/nim_windows_launcher.nim
build: implement code signing step for the Windows build Add a code signing step to the `pkg-windows` target. If the environment variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not set then a verified timestamp will not be included in the signature. Both variables should be set in production/CI builds. Signing is performed with Window's [SignTool][signtool]. There is a helpful [Stack Overflow answer][soa] which explains how to easily setup a self-signed CA and code signing certificate and then use them with `signtool`, which is how I tested these changes on my local Windows machine. Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally running other installations of those executables than the ones that ship with Git Bash. I was experiencing mysterious failures in the sequence of commands and then noticed that e.g. `which xargs` was resolving to an executable in `${HOME}/scoop/shims`. I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and Windows 10. For CI builds Status will need to acquire a signing certificate from e.g. DigiCert. There will be a yearly renewal cost. In researching what files should be signed, I concluded that it only makes sense to sign `.dll` and `.exe` files. It's possible to generate signatures for other file types but the signatures would have to be stored apart from those files, unlike `.dll` and `.exe` where the signature is embedded in the executable. Also, it doesn't seem to be possible to embed a signature in a `.zip` file, though it would be possible to sign the compressed package if we chose to build and distribute a self-extracting `Status.exe` instead of `Status.zip`. If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe sign` is not invoked on that file. Closes #288. [signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool [soa]: https://stackoverflow.com/a/201277
2020-07-21 16:28:42 +00:00
ifneq ($(WINDOWS_CODESIGN_TIMESTAMP_URL),)
WINDOWS_CODESIGN_TIMESTAMP_PARAM := -t $(WINDOWS_CODESIGN_TIMESTAMP_URL)
endif
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
STATUS_CLIENT_ZIP ?= pkg/Status.zip
$(STATUS_CLIENT_ZIP): nim_status_client nim_windows_launcher $(NIM_WINDOWS_PREBUILT_DLLS)
rm -rf pkg/*.zip
rm -rf tmp/windows/dist
mkdir -p tmp/windows/dist/Status/bin
mkdir -p tmp/windows/dist/Status/resources
mkdir -p tmp/windows/dist/Status/vendor
cp windows-install.txt tmp/windows/dist/Status/INSTALL.txt
unix2dos -k tmp/windows/dist/Status/INSTALL.txt
# cp LICENSE tmp/windows/dist/Status/LICENSE.txt
# unix2dos -k tmp/windows/dist/Status/LICENSE.txt
cp status.ico tmp/windows/dist/Status/resources/
cp status.svg tmp/windows/dist/Status/resources/
cp resources.rcc tmp/windows/dist/Status/resources/
cp $(FLEETS) tmp/windows/dist/Status/resources/
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
cp bin/nim_status_client.exe tmp/windows/dist/Status/bin/Status.exe
build: implement code signing step for the Windows build Add a code signing step to the `pkg-windows` target. If the environment variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not set then a verified timestamp will not be included in the signature. Both variables should be set in production/CI builds. Signing is performed with Window's [SignTool][signtool]. There is a helpful [Stack Overflow answer][soa] which explains how to easily setup a self-signed CA and code signing certificate and then use them with `signtool`, which is how I tested these changes on my local Windows machine. Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally running other installations of those executables than the ones that ship with Git Bash. I was experiencing mysterious failures in the sequence of commands and then noticed that e.g. `which xargs` was resolving to an executable in `${HOME}/scoop/shims`. I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and Windows 10. For CI builds Status will need to acquire a signing certificate from e.g. DigiCert. There will be a yearly renewal cost. In researching what files should be signed, I concluded that it only makes sense to sign `.dll` and `.exe` files. It's possible to generate signatures for other file types but the signatures would have to be stored apart from those files, unlike `.dll` and `.exe` where the signature is embedded in the executable. Also, it doesn't seem to be possible to embed a signature in a `.zip` file, though it would be possible to sign the compressed package if we chose to build and distribute a self-extracting `Status.exe` instead of `Status.zip`. If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe sign` is not invoked on that file. Closes #288. [signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool [soa]: https://stackoverflow.com/a/201277
2020-07-21 16:28:42 +00:00
cp bin/nim_windows_launcher.exe tmp/windows/dist/Status/Status.exe
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
rcedit \
tmp/windows/dist/Status/bin/Status.exe \
--set-icon tmp/windows/dist/Status/resources/status.ico
rcedit \
tmp/windows/dist/Status/Status.exe \
--set-icon tmp/windows/dist/Status/resources/status.ico
cp $(DOTHERSIDE) tmp/windows/dist/Status/bin/
cp $(STATUSGO) tmp/windows/dist/Status/bin/
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
cp tmp/windows/tools/*.dll tmp/windows/dist/Status/bin/
2020-08-10 20:19:15 +00:00
mkdir -p tmp/windows/dist/Status/resources/i18n
cp ui/i18n/* tmp/windows/dist/Status/resources/i18n
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
cp "$(shell which libgcc_s_seh-1.dll)" tmp/windows/dist/Status/bin/
cp "$(shell which libwinpthread-1.dll)" tmp/windows/dist/Status/bin/
echo -e $(BUILD_MSG) "deployable folder"
windeployqt \
--compiler-runtime \
--qmldir ui \
--release \
tmp/windows/dist/Status/bin/DOtherSide.dll
mv tmp/windows/dist/Status/bin/vc_redist.x64.exe tmp/windows/dist/Status/vendor/
build: implement code signing step for the Windows build Add a code signing step to the `pkg-windows` target. If the environment variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not set then a verified timestamp will not be included in the signature. Both variables should be set in production/CI builds. Signing is performed with Window's [SignTool][signtool]. There is a helpful [Stack Overflow answer][soa] which explains how to easily setup a self-signed CA and code signing certificate and then use them with `signtool`, which is how I tested these changes on my local Windows machine. Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally running other installations of those executables than the ones that ship with Git Bash. I was experiencing mysterious failures in the sequence of commands and then noticed that e.g. `which xargs` was resolving to an executable in `${HOME}/scoop/shims`. I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and Windows 10. For CI builds Status will need to acquire a signing certificate from e.g. DigiCert. There will be a yearly renewal cost. In researching what files should be signed, I concluded that it only makes sense to sign `.dll` and `.exe` files. It's possible to generate signatures for other file types but the signatures would have to be stored apart from those files, unlike `.dll` and `.exe` where the signature is embedded in the executable. Also, it doesn't seem to be possible to embed a signature in a `.zip` file, though it would be possible to sign the compressed package if we chose to build and distribute a self-extracting `Status.exe` instead of `Status.zip`. If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe sign` is not invoked on that file. Closes #288. [signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool [soa]: https://stackoverflow.com/a/201277
2020-07-21 16:28:42 +00:00
# if WINDOWS_CODESIGN_PFX_PATH is not set then DLLs, EXEs are not signed
ifdef WINDOWS_CODESIGN_PFX_PATH
find ./tmp/windows/dist/Status -type f \
| /usr/bin/egrep -i "\.(dll|exe)$$" \
| /usr/bin/xargs -I{} /usr/bin/bash -c \
"if ! '$(SIGNTOOL)' verify -pa {} &>/dev/null; then echo {}; fi" \
| /usr/bin/xargs -I{} "$(SIGNTOOL)" \
sign \
-v \
-f $(WINDOWS_CODESIGN_PFX_PATH) \
$(WINDOWS_CODESIGN_TIMESTAMP_PARAM) \
{}
endif
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
echo -e $(BUILD_MSG) "zip"
mkdir -p pkg
cd tmp/windows/dist/Status && \
7z a ../../../../$(STATUS_CLIENT_ZIP) *
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
pkg: $(PKG_TARGET)
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
pkg-linux: check-pkg-target-linux $(STATUS_CLIENT_APPIMAGE)
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
pkg-macos: check-pkg-target-macos $(STATUS_CLIENT_DMG)
2020-05-14 14:58:08 +00:00
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
pkg-windows: check-pkg-target-windows $(STATUS_CLIENT_ZIP)
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
2020-05-14 14:58:08 +00:00
clean: | clean-common
rm -rf bin/* node_modules bottles/* pkg/* tmp/* $(STATUSGO)
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
+ $(MAKE) -C vendor/DOtherSide/build --no-print-directory clean
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
run: rcc $(RUN_TARGET)
ICON_TOOL := node_modules/.bin/fileicon
$(ICON_TOOL):
echo -e "\e[92mInstalling:\e[39m fileicon"
npm i
NIM_STATUS_CLIENT_DEV ?= t
build: use a different colored app icon and a non-default STATUS_PORT for dev builds By default the desktop app uses port 30305, unless a value is specifically set in environment variable `STATUS_PORT`. For convenience of those developing the app and running development builds, while simultaneously running production builds (a.k.a. packaged builds, whether built locally or in CI), have `make run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can still be overriden by manually invoking `make run` with a different value, e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both valid and achieve the same effect. NOTE: the port "sticks" in the database after the first clean run, so when changing ports developers will need to delete the data dir within their local repository, else the existing database for dev builds will be stuck using whatever port was used previously. In the future, we can figure out a means to always update the port setting in the database just after the login event (but see #1505). Also, for development builds use an icon (for the running app) that is orangered (`#ff4500`) instead of the official blue color. This makes it much easier to select between a running production instance and development instance when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open applications. Not all icons displayed at runtime have been changed in this manner for development builds, just the main application icon, and that seems to be sufficient to achieve the desired effect; though in the future we could do similar for notification icon, menu bar icon, etc.
2020-12-16 01:15:44 +00:00
STATUS_PORT ?= 30306
set-status-macos-dev-icon: $(ICON_TOOL)
npx fileicon set bin/nim_status_client status-dev.icns
run-linux:
echo -e "\e[92mRunning:\e[39m bin/nim_status_client"
NIM_STATUS_CLIENT_DEV="$(NIM_STATUS_CLIENT_DEV)" \
LD_LIBRARY_PATH="$(QT5_LIBDIR)":"$(STATUSGO_LIBDIR)" \
build: use a different colored app icon and a non-default STATUS_PORT for dev builds By default the desktop app uses port 30305, unless a value is specifically set in environment variable `STATUS_PORT`. For convenience of those developing the app and running development builds, while simultaneously running production builds (a.k.a. packaged builds, whether built locally or in CI), have `make run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can still be overriden by manually invoking `make run` with a different value, e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both valid and achieve the same effect. NOTE: the port "sticks" in the database after the first clean run, so when changing ports developers will need to delete the data dir within their local repository, else the existing database for dev builds will be stuck using whatever port was used previously. In the future, we can figure out a means to always update the port setting in the database just after the login event (but see #1505). Also, for development builds use an icon (for the running app) that is orangered (`#ff4500`) instead of the official blue color. This makes it much easier to select between a running production instance and development instance when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open applications. Not all icons displayed at runtime have been changed in this manner for development builds, just the main application icon, and that seems to be sufficient to achieve the desired effect; though in the future we could do similar for notification icon, menu bar icon, etc.
2020-12-16 01:15:44 +00:00
STATUS_PORT="$(STATUS_PORT)" \
./bin/nim_status_client
run-macos: set-status-macos-dev-icon
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e "\e[92mRunning:\e[39m bin/nim_status_client"
NIM_STATUS_CLIENT_DEV="$(NIM_STATUS_CLIENT_DEV)" \
build: use a different colored app icon and a non-default STATUS_PORT for dev builds By default the desktop app uses port 30305, unless a value is specifically set in environment variable `STATUS_PORT`. For convenience of those developing the app and running development builds, while simultaneously running production builds (a.k.a. packaged builds, whether built locally or in CI), have `make run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can still be overriden by manually invoking `make run` with a different value, e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both valid and achieve the same effect. NOTE: the port "sticks" in the database after the first clean run, so when changing ports developers will need to delete the data dir within their local repository, else the existing database for dev builds will be stuck using whatever port was used previously. In the future, we can figure out a means to always update the port setting in the database just after the login event (but see #1505). Also, for development builds use an icon (for the running app) that is orangered (`#ff4500`) instead of the official blue color. This makes it much easier to select between a running production instance and development instance when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open applications. Not all icons displayed at runtime have been changed in this manner for development builds, just the main application icon, and that seems to be sufficient to achieve the desired effect; though in the future we could do similar for notification icon, menu bar icon, etc.
2020-12-16 01:15:44 +00:00
STATUS_PORT="$(STATUS_PORT)" \
./bin/nim_status_client
2020-05-14 14:58:08 +00:00
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
run-windows: $(NIM_WINDOWS_PREBUILT_DLLS)
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
echo -e "\e[92mRunning:\e[39m bin/nim_status_client.exe"
NIM_STATUS_CLIENT_DEV="$(NIM_STATUS_CLIENT_DEV)" \
PATH="$(shell pwd)"/"$(shell dirname "$(DOTHERSIDE)")":"$(STATUSGO_LIBDIR)":"$(shell pwd)"/"$(shell dirname "$(NIM_WINDOWS_PREBUILT_DLLS)")":"$(PATH)" \
build: use a different colored app icon and a non-default STATUS_PORT for dev builds By default the desktop app uses port 30305, unless a value is specifically set in environment variable `STATUS_PORT`. For convenience of those developing the app and running development builds, while simultaneously running production builds (a.k.a. packaged builds, whether built locally or in CI), have `make run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can still be overriden by manually invoking `make run` with a different value, e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both valid and achieve the same effect. NOTE: the port "sticks" in the database after the first clean run, so when changing ports developers will need to delete the data dir within their local repository, else the existing database for dev builds will be stuck using whatever port was used previously. In the future, we can figure out a means to always update the port setting in the database just after the login event (but see #1505). Also, for development builds use an icon (for the running app) that is orangered (`#ff4500`) instead of the official blue color. This makes it much easier to select between a running production instance and development instance when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open applications. Not all icons displayed at runtime have been changed in this manner for development builds, just the main application icon, and that seems to be sufficient to achieve the desired effect; though in the future we could do similar for notification icon, menu bar icon, etc.
2020-12-16 01:15:44 +00:00
STATUS_PORT="$(STATUS_PORT)" \
./bin/nim_status_client.exe
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
2020-05-14 14:58:08 +00:00
endif # "variables.mk" was not included