status-im
/
status-desktop
mirror of https://github.com/status-im/status-desktop.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
status-desktop/Makefile

460 lines
16 KiB
Makefile
Raw Normal View History

Adding nimbus-build-system
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.
feat: makefile
2020-05-06 21:26:32 +00:00
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
SHELL := bash # the shell used internally by Make
add make-osx task
2020-05-06 21:43:20 +00:00
Adding nimbus-build-system
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 \
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
clean \
deps \
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
fleets-remove \
fleets-update \
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
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 \
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
run \
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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 \
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
status-go \
Adding nimbus-build-system
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.
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
all: nim_status_client
# must be included after the default target
-include $(BUILD_SYSTEM_DIR)/makefiles/targets.mk
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
ifeq ($(OS),Windows_NT) # is Windows_NT on XP, 2000, 7, Vista, 10...
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
detected_OS := Windows
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
else
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
detected_OS := $(strip $(shell uname))
Adding nimbus-build-system
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)
build: fetch macOS Homebrew bottles from GitHub Packages instead of bintray bintray (for open source) is shutting down permanently on May 1: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ At this time downloading from GitHub Packages requires specifying a username and personal acccess token, but it seems they don't have to be valid. For example, in the changes to the Makefile I specified `_:_` as the username and token. Also, change the minimum macOS version from 10.13 to 10.14 since Homebrew bottles are no longer built for 10.13 (High Sierra): https://github.com/Homebrew/discussions/discussions/1264#discussioncomment-601544 Closes #1851
2021-04-13 19:03:19 +00:00
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
build: fetch macOS Homebrew bottles from GitHub Packages instead of bintray bintray (for open source) is shutting down permanently on May 1: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ At this time downloading from GitHub Packages requires specifying a username and personal acccess token, but it seems they don't have to be valid. For example, in the changes to the Makefile I specified `_:_` as the username and token. Also, change the minimum macOS version from 10.13 to 10.14 since Homebrew bottles are no longer built for 10.13 (High Sierra): https://github.com/Homebrew/discussions/discussions/1264#discussioncomment-601544 Closes #1851
2021-04-13 19:03:19 +00:00
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
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
LIBSTATUS_EXT := dylib
build: fetch macOS Homebrew bottles from GitHub Packages instead of bintray bintray (for open source) is shutting down permanently on May 1: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ At this time downloading from GitHub Packages requires specifying a username and personal acccess token, but it seems they don't have to be valid. For example, in the changes to the Makefile I specified `_:_` as the username and token. Also, change the minimum macOS version from 10.13 to 10.14 since Homebrew bottles are no longer built for 10.13 (High Sierra): https://github.com/Homebrew/discussions/discussions/1264#discussioncomment-601544 Closes #1851
2021-04-13 19:03:19 +00:00
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
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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)
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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 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
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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
build: use GitHub credentials when downloading bottles for macOS Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-15 21:14:30 +00:00
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
fix: don't run scripts/fetch-brew-bottle.sh in parallel It's not supported to run `brew update` multiple times simultaenously. A better fix for this can be implemented, but for now in the Makefile have target `bottles/pcre` depend on target `bottles/openssl` so that they run serially when `-jN` is passed to `make`. I was originally going to change `brew update >/dev/null` to `brew update >/dev/null || true` but decided the Makefile change provides a better guarantee that simultaenous `brew` commands won't interfere with each other. In the process, I revised some of the script's `echo` output just a bit.
2021-04-16 17:36:53 +00:00
bottles/pcre: bottles/openssl
build: use GitHub credentials when downloading bottles for macOS Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-15 21:14:30 +00:00
./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
build: use GitHub credentials when downloading bottles for macOS Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-15 21:14:30 +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
Adding nimbus-build-system
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
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
# 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 ...")
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
else
refactor: $QTDIR should include the compiler-arch path segment
2020-06-25 21:04:47 +00:00
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
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
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
# 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
NIM_PARAMS += -L:$(DOTHERSIDE)
NIM_EXTRA_PARAMS := --passL:"-lsetupapi -lhid"
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
endif
build: bump vendor/DOtherSide Fix a typo in a recently added header file in DOtherSide that causes problems on case-sensitive filesystems, e.g. on Linux. Also unify the build command for DOtherSide across platforms.
2021-05-27 22:32:33 +00:00
DOTHERSIDE_BUILD_CMD := cmake --build . --config Release $(HANDLE_OUTPUT)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
RELEASE ?= false
ifeq ($(RELEASE),false)
# We need `-d:debug` to get Nim's default stack traces
NIM_PARAMS += -d:debug
# Enable debugging symbols in DOtherSide, in case we need GDB backtraces
CFLAGS += -g
CXXFLAGS += -g
perf(@desktop): "make run" boost and build correct qrc
2021-07-19 06:05:15 +00:00
RCC_PARAMS = --no-compress
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
else
# Additional optimization flags for release builds are not included at present;
# adding them will involve refactoring config.nims in the root of this repo
NIM_PARAMS += -d:release
endif
NIM_PARAMS += --outdir:./bin
Adding nimbus-build-system
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 && \
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
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)\
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
-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)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
STATUSGO := vendor/status-go/build/bin/libstatus.$(LIBSTATUS_EXT)
STATUSGO_LIBDIR := $(shell pwd)/$(shell dirname "$(STATUSGO)")
export STATUSGO_LIBDIR
AppImg packaging
2020-05-14 20:19:01 +00:00
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
status-go: $(STATUSGO)
AppImg packaging
2020-05-14 20:19:01 +00:00
$(STATUSGO): | deps
echo -e $(BUILD_MSG) "status-go"
+ cd vendor/status-go && \
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
$(MAKE) statusgo-shared-library $(HANDLE_OUTPUT)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
feat: show qr codes
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)
feat: show qr codes
2020-06-23 17:17:58 +00:00
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
FLEETS := fleets.json
$(FLEETS):
echo -e $(BUILD_MSG) "Getting latest $(FLEETS)"
feat: use fleets.json to set the node config
2020-11-03 19:42:55 +00:00
curl -s https://fleets.status.im/ \
| jq --indent 4 --sort-keys . \
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
> $(FLEETS)
feat: use fleets.json to set the node config
2020-11-03 19:42:55 +00:00
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
fleets-remove:
rm -f $(FLEETS)
Update docker linux version
2020-11-06 15:50:58 +00:00
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
fleets-update: fleets-remove $(FLEETS)
refactor: embed Infura key at compile time Allow environmental override at runtime. Also, in the Makefile set a free-tier default token so that setting up an Infura account isn't strictly necessary for community contributors to build the app, even though in our docs it should be recommended they do so. Core contributors should setup their own free-tier Infura account, create a key, and set it in the environment variable INFURA_TOKEN in their environment used to build the desktop app locally. There is one aspect of this work that is incomplete. Ideally, in the handler for the `login` event the relevant settings in the database should always be updated with the resolved Infura key. However, when calling `getSetting[string](Setting.Networks_Networks)` in the handler it causes a segfault every time. Neither the reason for the crash nor a workaround have been worked out at this time.
2020-10-30 01:53:34 +00:00
feat: bundle resources - Update linux build to package resources - Refactor macOS packaging re: resources.rcc
2020-06-30 21:35:24 +00:00
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"
fix: rm the correct paths for resources.qrc|rcc
2020-07-07 18:13:41 +00:00
rm -f ./resources.rcc
rm -f ./ui/resources.qrc
perf(@desktop): "make run" boost and build correct qrc
2021-07-19 06:05:15 +00:00
go run ui/generate-rcc.go -source=ui -output=ui/resources.qrc
rcc -binary $(RCC_PARAMS) ui/resources.qrc -o ./resources.rcc
feat: bundle resources - Update linux build to package resources - Refactor macOS packaging re: resources.rcc
2020-06-30 21:35:24 +00:00
refactor: embed Infura key at compile time Allow environmental override at runtime. Also, in the Makefile set a free-tier default token so that setting up an Infura account isn't strictly necessary for community contributors to build the app, even though in our docs it should be recommended they do so. Core contributors should setup their own free-tier Infura account, create a key, and set it in the environment variable INFURA_TOKEN in their environment used to build the desktop app locally. There is one aspect of this work that is incomplete. Ideally, in the handler for the `login` event the relevant settings in the database should always be updated with the resolved Infura key. However, when calling `getSetting[string](Setting.Networks_Networks)` in the handler it causes a segfault every time. Neither the reason for the crash nor a workaround have been worked out at this time.
2020-10-30 01:53:34 +00:00
# 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)"
feat(@desktop/chat): Display gif popup next to emoji
2021-07-21 08:26:31 +00:00
DEFAULT_TENOR_API_KEY := DU7DWZ27STB2
TENOR_API_KEY ?= $(DEFAULT_TENOR_API_KEY)
NIM_PARAMS += -d:TENOR_API_KEY:"$(TENOR_API_KEY)"
chore: add chronicles configuration to output logs to a file
2021-06-29 18:42:18 +00:00
# generate a status-desktop.log file with chronicles output. This file will be truncated each time the app starts
NIM_PARAMS += -d:chronicles_sinks="textlines[stdout],textlines[nocolors,file(status-desktop.log,truncate)]"
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
RESOURCES_LAYOUT := -d:development
nim_status_client: NIM_PARAMS += $(RESOURCES_LAYOUT)
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
nim_status_client: | $(DOTHERSIDE) $(STATUSGO) $(QRCODEGEN) $(FLEETS) rcc deps
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
echo -e $(BUILD_MSG) "$@" && \
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
$(ENV_SCRIPT) nim c $(NIM_PARAMS) --passL:"-L$(STATUSGO_LIBDIR)" --passL:"-lstatus" $(NIM_EXTRA_PARAMS) --passL:"$(QRCODEGEN)" --passL:"-lm" src/nim_status_client.nim && \
build: don't swallow error when make fails to build bin/nim_status_client
2020-09-03 16:06:36 +00:00
[[ $$? = 0 ]] && \
(([[ $(detected_OS) = Darwin ]] && \
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
install_name_tool -change \
libstatus.dylib \
@rpath/libstatus.dylib \
build: don't swallow error when make fails to build bin/nim_status_client
2020-09-03 16:06:36 +00:00
bin/nim_status_client) || true)
AppImg packaging
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)
feat: make run
2020-05-19 15:32:48 +00:00
build: use same container as Jenkins CI for local packaged builds on Linux Make the docker-related logic for doing a local packaged build on Linux match with the Jenkins CI build for Linux. Also fix the problems with packaged builds for Linux (local or CI) where gstreamer errors were displayed in the terminal shortly after app start/login and there was no sound output.
2021-04-21 20:13:21 +00:00
STATUS_CLIENT_APPIMAGE ?= pkg/Status.AppImage
build: on Linux use tar+gzip to preserve +x attribute of .AppImage We create a separate make target to avoid tarballing every time. This is really useful only for releases we upload for users. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-06-04 19:44:39 +00:00
STATUS_CLIENT_TARBALL ?= pkg/Status.tar.gz
AppImg packaging
2020-05-14 20:19:01 +00:00
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
$(STATUS_CLIENT_APPIMAGE): override RESOURCES_LAYOUT := -d:production
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +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
chore: DOtherSide shared lib extension differs by platform `.so` for Linux, `.dylib` for macOS
2020-05-18 16:51:29 +00:00
ft: AppImage
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
feat: bundle resources - Update linux build to package resources - Refactor macOS packaging re: resources.rcc
2020-06-30 21:35:24 +00:00
cp status.svg tmp/linux/dist/usr/.
cp -R resources.rcc tmp/linux/dist/usr/.
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
cp -R $(FLEETS) tmp/linux/dist/usr/.
change path to resources
2020-08-10 20:19:15 +00:00
mkdir -p tmp/linux/dist/usr/i18n
cp ui/i18n/* tmp/linux/dist/usr/i18n
ft: AppImage
2020-05-15 13:00:49 +00:00
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
# Libraries
test: copying nss libs
2020-10-07 15:24:24 +00:00
cp -r /usr/lib/x86_64-linux-gnu/nss tmp/linux/dist/usr/lib/
build: use same container as Jenkins CI for local packaged builds on Linux Make the docker-related logic for doing a local packaged build on Linux match with the Jenkins CI build for Linux. Also fix the problems with packaged builds for Linux (local or CI) where gstreamer errors were displayed in the terminal shortly after app start/login and there was no sound output.
2021-04-21 20:13:21 +00:00
cp -P /usr/lib/x86_64-linux-gnu/libgst* tmp/linux/dist/usr/lib/
cp -r /usr/lib/x86_64-linux-gnu/gstreamer-1.0 tmp/linux/dist/usr/lib/
cp -r /usr/lib/x86_64-linux-gnu/gstreamer1.0 tmp/linux/dist/usr/lib/
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
cp vendor/status-go/build/bin/libstatus.so tmp/linux/dist/usr/lib/
AppImg packaging
2020-05-14 20:19:01 +00:00
echo -e $(BUILD_MSG) "AppImage"
feat: get and display emoji reactions in chat
2020-08-12 15:01:03 +00:00
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
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
$(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
build: on Linux use tar+gzip to preserve +x attribute of .AppImage We create a separate make target to avoid tarballing every time. This is really useful only for releases we upload for users. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-06-04 19:44:39 +00:00
$(STATUS_CLIENT_TARBALL): $(STATUS_CLIENT_APPIMAGE)
tar czvf $(STATUS_CLIENT_TARBALL) \
-C $(shell dirname $(STATUS_CLIENT_APPIMAGE)) \
$(shell basename $(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
ft: AppImage
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
ft: AppImage
2020-05-15 13:00:49 +00:00
feat: reintroduce the dapp browser
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
AppImg packaging
2020-05-14 20:19:01 +00:00
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +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
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
$(STATUS_CLIENT_DMG): override RESOURCES_LAYOUT := -d:production
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +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
feat: reintroduce the dapp browser
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/
chore: revise how dev version of app icon is set on macOS during `make run` The way it was done previously didn't always produce the intended result (for unknown reasons), i.e. the dev app would sometimes launch with a transparent blank square appearing in place of the expected icon.
2021-01-19 16:10:36 +00:00
cp status.icns $(MACOS_OUTER_BUNDLE)/Contents/Resources/
chore(@desktop/general): use different icons for Windows/Linux and MacOS Icons are updated, mac uses rounded rect log, win and linux circle logo. Fixes: #2833
2021-07-19 16:00:05 +00:00
cp status-macos.svg $(MACOS_OUTER_BUNDLE)/Contents/
feat: reintroduce the dapp browser
2020-09-22 15:12:48 +00:00
cp -R resources.rcc $(MACOS_OUTER_BUNDLE)/Contents/
refactor: in Windows packaged build fleets.json should be in resources/ In the context of Windows packaged builds, this is consistent with other resources needed by the application; organizing them in this way keeps the top-level directory of Windows packaged builds clear of files that most users should never have to see or think about.
2020-12-10 16:56:32 +00:00
cp -R $(FLEETS) $(MACOS_OUTER_BUNDLE)/Contents/
feat: reintroduce the dapp browser
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 \
feat: reintroduce the dapp browser
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
feat: reintroduce the dapp browser
2020-09-22 15:12:48 +00:00
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
feat: reintroduce the dapp browser
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
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
ifdef MACOS_CODESIGN_IDENT
feat: reintroduce the dapp browser
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
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +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
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" \
feat: reintroduce the dapp browser
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
add Jenkinsfiles and Dockerfile for CI Changes: - Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds - Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms - Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script - Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG - Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment - Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-06-18 16:44:22 +00:00
# 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
ci: implement MacOS notarization using xcrun altool This introduces an automated MacOS notarization process for Jenkins CI. The process involves: * Uploading the signed DMG file to the notary service * Checking periodically if the scanning process has completed * Stapling the successful scan ticket to the DMG file This is done by the `scripts/notarize-macos-pkg.sh` via the `make notarize-macos` target. The whole process is described in more details in `docs/macos_notarization.md`. Depends on: https://github.com/status-im/status-jenkins-lib/pull/27 Resolves: https://github.com/status-im/status-desktop/issues/2169 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-05-27 07:53:40 +00:00
notarize-macos: export CHECK_INTERVAL_SEC ?= 30
notarize-macos: export CHECK_RETRY_LIMIT ?= 20
notarize-macos: export MACOS_BUNDLE_ID ?= im.status.ethereum.desktop
notarize-macos:
scripts/notarize-macos-pkg.sh $(STATUS_CLIENT_DMG)
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 && \
ci: scripts/sign-windows-bin.sh for signing Windows binaries This introduces the `scripts/sign-windows-bin.sh` script which is used by the `Makefile` to sign application libraries and executables. It also implements the logic necessary to distinguish between different types of builds: release and non-release builds. Some other changes: * Refactore the `Makefile` target that creates the Windows ZIP to make less verbose. * Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component * Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-19 14:45:46 +00:00
wget -nv https://nim-lang.org/download/dlls.zip && \
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
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
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
STATUS_CLIENT_EXE ?= pkg/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
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
$(STATUS_CLIENT_EXE): override RESOURCES_LAYOUT := -d:production
$(STATUS_CLIENT_EXE): OUTPUT := tmp/windows/dist/Status
$(STATUS_CLIENT_EXE): INSTALLER_OUTPUT := pkg
$(STATUS_CLIENT_EXE): nim_status_client nim_windows_launcher $(NIM_WINDOWS_PREBUILT_DLLS)
rm -rf pkg/*.exe tmp/windows/dist
ci: scripts/sign-windows-bin.sh for signing Windows binaries This introduces the `scripts/sign-windows-bin.sh` script which is used by the `Makefile` to sign application libraries and executables. It also implements the logic necessary to distinguish between different types of builds: release and non-release builds. Some other changes: * Refactore the `Makefile` target that creates the Windows ZIP to make less verbose. * Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component * Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-19 14:45:46 +00:00
mkdir -p $(OUTPUT)/bin $(OUTPUT)/resources $(OUTPUT)/vendor $(OUTPUT)/resources/i18n
cat windows-install.txt | unix2dos > $(OUTPUT)/INSTALL.txt
cp status.ico status.svg resources.rcc $(FLEETS) $(OUTPUT)/resources/
cp ui/i18n/* $(OUTPUT)/resources/i18n
cp bin/nim_status_client.exe $(OUTPUT)/bin/Status.exe
cp bin/nim_windows_launcher.exe $(OUTPUT)/Status.exe
rcedit $(OUTPUT)/bin/Status.exe --set-icon $(OUTPUT)/resources/status.ico
rcedit $(OUTPUT)/Status.exe --set-icon $(OUTPUT)/resources/status.ico
cp $(DOTHERSIDE) $(STATUSGO) tmp/windows/tools/*.dll $(OUTPUT)/bin/
cp "$(shell which libgcc_s_seh-1.dll)" $(OUTPUT)/bin/
cp "$(shell which libwinpthread-1.dll)" $(OUTPUT)/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
echo -e $(BUILD_MSG) "deployable folder"
ci: scripts/sign-windows-bin.sh for signing Windows binaries This introduces the `scripts/sign-windows-bin.sh` script which is used by the `Makefile` to sign application libraries and executables. It also implements the logic necessary to distinguish between different types of builds: release and non-release builds. Some other changes: * Refactore the `Makefile` target that creates the Windows ZIP to make less verbose. * Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component * Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-19 14:45:46 +00:00
windeployqt --compiler-runtime --qmldir ui --release \
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
tmp/windows/dist/Status/bin/DOtherSide.dll
mv tmp/windows/dist/Status/bin/vc_redist.x64.exe tmp/windows/dist/Status/vendor/
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
cp status.iss $(OUTPUT)/status.iss
ci: scripts/sign-windows-bin.sh for signing Windows binaries This introduces the `scripts/sign-windows-bin.sh` script which is used by the `Makefile` to sign application libraries and executables. It also implements the logic necessary to distinguish between different types of builds: release and non-release builds. Some other changes: * Refactore the `Makefile` target that creates the Windows ZIP to make less verbose. * Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component * Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-19 14:45:46 +00:00
# if WINDOWS_CODESIGN_PFX_PATH is not set then DLLs, EXEs are not signed
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
ifdef WINDOWS_CODESIGN_PFX_PATH
ci: scripts/sign-windows-bin.sh for signing Windows binaries This introduces the `scripts/sign-windows-bin.sh` script which is used by the `Makefile` to sign application libraries and executables. It also implements the logic necessary to distinguish between different types of builds: release and non-release builds. Some other changes: * Refactore the `Makefile` target that creates the Windows ZIP to make less verbose. * Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component * Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-19 14:45:46 +00:00
scripts/sign-windows-bin.sh ./tmp/windows/dist/Status
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
endif
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
echo -e $(BUILD_MSG) "exe"
mkdir -p $(INSTALLER_OUTPUT)
ISCC \
-O"$(INSTALLER_OUTPUT)" \
-D"BaseName=$(shell basename $(STATUS_CLIENT_EXE) .exe)" \
-D"Version=$(shell cat VERSION)" \
$(OUTPUT)/status.iss
ifdef WINDOWS_CODESIGN_PFX_PATH
scripts/sign-windows-bin.sh $(INSTALLER_OUTPUT)
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
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: on Linux use tar+gzip to preserve +x attribute of .AppImage We create a separate make target to avoid tarballing every time. This is really useful only for releases we upload for users. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-06-04 19:44:39 +00:00
tgz-linux: $(STATUS_CLIENT_TARBALL)
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)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
pkg-windows: check-pkg-target-windows $(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
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
clean: | clean-common
build: use GitHub credentials when downloading bottles for macOS Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-15 21:14:30 +00:00
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)
chore: revise how dev version of app icon is set on macOS during `make run` The way it was done previously didn't always produce the intended result (for unknown reasons), i.e. the dev app would sometimes launch with a transparent blank square appearing in place of the expected icon.
2021-01-19 16:10:36 +00:00
ICON_TOOL := node_modules/.bin/fileicon
$(ICON_TOOL):
echo -e "\e[92mInstalling:\e[39m fileicon"
npm i
feat: command-line option can be used to specify app's data directory In the repo: ``` $ bin/nim_status_client --help ``` In the packaged app (macOS example): ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --help ``` Output: ``` Usage: nim_status_client [OPTIONS]... The following options are available: -d, --dataDir Status Desktop data directory. ``` **Using the option** ``` $ cd ~/status-ci-builds/master/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/master" ``` In another terminal: ``` $ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS $ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242" ``` The path supplied can be relative or absolute, and can be specified with `--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`. Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]` or `-d [path]`. The name of the option follows Nim's partial case-insensitivity rules, so `--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See [Identifier equality][ieq] in the Nim Manual. It is possible to run the same build in multiple terminals by supplying different `--dataDir`, i.e. this works: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some1" ``` In another terminal: ``` $ cd /Applications/Status.app/Contents/MacOS $ ./nim_status_client --dataDir="${HOME}/temp/some2" ``` **Windows** It is recommended to use a Git Bash or MSYS2 terminal when invoking `bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production build) on the command-line. The reason is that if the exe is invoked in a session of `cmd.exe` it will return to the prompt immediately; the app will run but there will be no output in the terminal. In any case, the `--dataDir` option will take effect whether the exe is invoked in `cmd.exe` or a recommended terminal. For development builds, when invoking `bin/nim_status_client.exe` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to first setup the `PATH` environment variable correctly. See the `run-windows` target in this repo's Makefile for more information. **Linux** The `--dataDir` option may be passed to command-line invocation of a production (AppImage) build in the same way as passing it to a development build: ``` $ Status.AppImage --dataDir:/path/to/wherever ``` For development builds, when invoking `bin/nim_status_client` directly instead of via `make run`, because e.g. you wish to use the `--dataDir` option, it is required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the `run-linux` target in this repo's Makefile for more information. --- BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling of the status-go directory rather than a subdir of the status-go directory: ``` Status (app data directory) ├── data (status-go directory) ├── qt └── tmp ``` Because app settings are stored in the `qt` directory that means that existing installations will lose their customized settings. At app startup, it would be possible to detect `Status/data/qt` and if `Status/qt` doesn't exist yet then copy `Status/data/qt` to `Status/qt`. However, there was some concern that behavior could lead to problems later on if we forget the workaround is in place. So for now that settings preservation strategy has not been implemented, but it might be before this commit is merged pending full team awareness/consensus. --- Command-line option support is provided by [nim-confutils](https://github.com/status-im/nim-confutils). The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of passing a "define" option to the Nim compiler: `-d:development` for development builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make V=1 pkg`). Passing the correct option is handled automatically by the Makefile. A make variable named `RELEASE` has been introduced, which defaults to `false`. Presently the `RELEASE` variable should not be set on the command-line nor in CI as more work needs to be done to toggle the proper compiler flags. In the case of Status Desktop, "release vs. debug" is a concern orthogonal to "production vs. development". At present, production builds and development builds are all debug builds, but that will likely change in the future: we can have non-release CI production builds and local development builds be debug builds, while release builds in CI would be production builds with `RELEASE=true` (the compiled executable will be fully optimized). Prior to the changes in this PR, symmetry is somewhat lacking between development and production (packaged) builds with respect to the concept of the "data directory". In development builds the root of the repo effectively serves as the `Status` directory used by production builds, e.g. on macOS `~/Library/Application Support/Status`. Also, there's a bit of confusion as to whether "data directory" refers to a directory for the desktop app's overall data (including status-go data) or to the specific directory used by status-go. This PR attempts to provide symmetry and reduce confusion: * The term "data directory" means the directory used by the desktop app to store multiple kinds of data and is not a reference to the subdirectory used by status-go. * For development builds the "data directory" defaults to `./Status/` relative to the root of the repo. * For production builds the "data directory" default is the same as before, e.g. on macOS it's ` ~/Library/Application Support/Status/`. The directory used by status-go is `Status/data/`. To be clear, that should be referred to as the "status-go directory" and not the app's "data directory". It would nice if we could rename it from `Status/data/` to `Status/status-go/`. We can do that, I already checked that it works correctly; however, for existing installations it would require that at app launch we check for the presence of `Status/data/` and rename it to `Status/status-go`. While simple enough to do, I was concerned that there might be edge cases where the directory rename could cause a problem (e.g. if another copy of the app is running) so chose for now to stick with the status-go directory being `Status/data/`. --- **NOTES** More work needs to be done to ensure that all data written by the app is contained in the default or cli-specified data directory. Currently, both development and production (packaged) builds are writing to common directories outside of the data directory, e.g. located within `~/Library/` on macOS. Changing that behavior seems like it will mainly involve changing defaults related to Qt components such as the web engine. See: https://github.com/status-im/status-desktop/issues/1141. In general, additional refactoring could be done in the future. For example, implementing `StatusDesktopConfig` in `src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine for now, but better code organization is desirable. --- Closes #2268 [ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
# Currently not in use: https://github.com/status-im/status-desktop/pull/1858
# STATUS_PORT ?= 30306
refactor: store data folder in OS appropriate location If the environment variable `NIM_STATUS_CLIENT_DEV` is not empty then the `./data` dir is created/used relative to the current working directory, as was always the case prior to the changes introduced in this commit. `NIM_STATUS_CLIENT_DEV` is set to `t` when doing `make run`. To get the production behavior in development do: ``` $ NIM_STATUS_CLIENT_DEV="" make run ``` or on Windows in a Bash shell: ``` $ NIM_STATUS_CLIENT_DEV="" mingw32-make run ``` Closes #391
2020-07-03 19:22:15 +00:00
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
run-linux:
echo -e "\e[92mRunning:\e[39m bin/nim_status_client"
LD_LIBRARY_PATH="$(QT5_LIBDIR)":"$(STATUSGO_LIBDIR)" \
./bin/nim_status_client
build: modify run logic for macOS dev builds so notifications work
2021-04-30 18:58:55 +00:00
run-macos: $(ICON_TOOL)
mkdir -p bin/StatusDev.app/Contents/{MacOS,Resources}
cp Info.dev.plist bin/StatusDev.app/Contents/Info.plist
cp status-dev.icns bin/StatusDev.app/Contents/Resources/
cd bin/StatusDev.app/Contents/MacOS && \
ln -fs ../../../nim_status_client ./
npx fileicon set bin/nim_status_client status-dev.icns
echo -e "\e[92mRunning:\e[39m bin/StatusDev.app/Contents/MacOS/nim_status_client"
./bin/StatusDev.app/Contents/MacOS/nim_status_client
Adding nimbus-build-system
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"
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
PATH="$(shell pwd)"/"$(shell dirname "$(DOTHERSIDE)")":"$(STATUSGO_LIBDIR)":"$(shell pwd)"/"$(shell dirname "$(NIM_WINDOWS_PREBUILT_DLLS)")":"$(PATH)" \
refactor: store data folder in OS appropriate location If the environment variable `NIM_STATUS_CLIENT_DEV` is not empty then the `./data` dir is created/used relative to the current working directory, as was always the case prior to the changes introduced in this commit. `NIM_STATUS_CLIENT_DEV` is set to `t` when doing `make run`. To get the production behavior in development do: ``` $ NIM_STATUS_CLIENT_DEV="" make run ``` or on Windows in a Bash shell: ``` $ NIM_STATUS_CLIENT_DEV="" mingw32-make run ``` Closes #391
2020-07-03 19:22:15 +00:00
./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
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
endif # "variables.mk" was not included