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

634 lines
22 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 \
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
compile-translations \
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
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 \
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
status-keycard-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)
chore: improve the bottles logic in Makefile With these changes it will be easier to maintain, i.e. to add/remove bottles just modify the `BOTTLES :=` list. `brew update` is removed from `scripts/fetch-brew-bottle.sh` and instead done in an [order-only prerequisite](https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html). This allows multiple bottles to be fetched in parallel (e.g. `make -j16`) without overlapping invocations of `brew update` (which causes script failure).
2021-09-16 22:32:00 +00:00
BOTTLES_DIR := $(shell pwd)/bottles
fix: on macOS download openssl@1.1 bottle because openssl bottle is now alias for openssl@3
2021-09-24 16:12:47 +00:00
BOTTLES := $(addprefix $(BOTTLES_DIR)/,hunspell openssl@1.1 pcre)
chore: improve the bottles logic in Makefile With these changes it will be easier to maintain, i.e. to add/remove bottles just modify the `BOTTLES :=` list. `brew update` is removed from `scripts/fetch-brew-bottle.sh` and instead done in an [order-only prerequisite](https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html). This allows multiple bottles to be fetched in parallel (e.g. `make -j16`) without overlapping invocations of `brew update` (which causes script failure).
2021-09-16 22:32:00 +00:00
$(BOTTLES): | $(BOTTLES_DIR)
echo -e "\e[92mFetching:\e[39m $(notdir $@) bottle"
./scripts/fetch-brew-bottle.sh $(notdir $@)
$(BOTTLES_DIR):
echo -e "\e[92mUpdating:\e[39m macOS Homebrew"
if [[ $$(stat -f %u /usr/local/var/homebrew) -ne "$${UID}" ]]; then \
echo "Missing permissions to update Homebrew formulae!" >&2; \
else \
brew update >/dev/null; \
mkdir -p $(BOTTLES_DIR); \
fi
bottles: $(BOTTLES)
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
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
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
QML_DEBUG ?= false
QML_DEBUG_PORT ?= 49152
ifneq ($(QML_DEBUG), false)
DOTHERSIDE_CMAKE_PARAMS := -DCMAKE_BUILD_TYPE=Debug -DQML_DEBUG_PORT=$(QML_DEBUG_PORT)
DOTHERSIDE_BUILD_CMD := cmake --build . --config Debug $(HANDLE_OUTPUT)
else
DOTHERSIDE_CMAKE_PARAMS := -DCMAKE_BUILD_TYPE=Release
DOTHERSIDE_BUILD_CMD := cmake --build . --config Release $(HANDLE_OUTPUT)
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
# 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)
feature(desktop/general): Display mentions number on tray icon badge. Count all mentions from all chats and communities. Send it to notifications object. Issue #4922
2022-04-01 16:14:48 +00:00
NIM_PARAMS += -L:"-framework Foundation -framework AppKit -framework Security -framework IOKit -framework CoreServices -framework LocalAuthentication"
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
# 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)"
feat(Spellchecking): Add bottle for spellchecking Usage: ```qml SpellChecker { id: spellchecker lang: "en" } ``` Closes: #3442
2021-09-10 12:47:07 +00:00
HUNSPELL := bottles/hunspell/lib/libhunspell-1.7.a
NIM_PARAMS += --passL:"$(HUNSPELL)"
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 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
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
DOTHERSIDE_CMAKE_PARAMS += -DENABLE_DYNAMIC_LIBS=OFF -DENABLE_STATIC_LIBS=ON
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
# order matters here, due to "-Wl,-as-needed"
fix(@desktop/general): app/os notifications Fixes #4409
2022-02-09 17:35:59 +00:00
NIM_PARAMS += --passL:"$(DOTHERSIDE)" --passL:"$(shell PKG_CONFIG_PATH="$(QT5_PCFILEDIR)" pkg-config --libs Qt5Core Qt5Qml Qt5Gui Qt5Quick Qt5QuickControls2 Qt5Widgets Qt5Svg Qt5Multimedia)"
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
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
ifneq ($(QML_DEBUG), false)
DOTHERSIDE := vendor/DOtherSide/build/lib/Debug/DOtherSide.dll
else
DOTHERSIDE := vendor/DOtherSide/build/lib/Release/DOtherSide.dll
endif
DOTHERSIDE_CMAKE_PARAMS += -T"v141" -A x64 -DENABLE_DYNAMIC_LIBS=ON -DENABLE_STATIC_LIBS=OFF
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
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
crosscompile to amd64 when building on darwin/arm64
2021-09-23 13:38:38 +00:00
ifeq ($(detected_OS),Darwin)
ifeq ("$(shell sysctl -nq hw.optional.arm64)","1")
# Building on M1 is still not supported, so in the meantime we crosscompile to amd64
DOTHERSIDE_CMAKE_PARAMS += -DCMAKE_OSX_ARCHITECTURES=x86_64
NIM_PARAMS += --cpu:amd64 --os:MacOSX --passL:"-arch x86_64" --passC:"-arch x86_64"
endif
endif
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
feat: Version Updating Fixes #1290
2021-06-17 18:41:11 +00:00
# App version
VERSIONFILE=VERSION
DESKTOP_VERSION=`cat $(VERSIONFILE)`
NIM_PARAMS += -d:DESKTOP_VERSION="$(DESKTOP_VERSION)"
feature(desktop/internal): Improve log file naming convention Logs are named app_yyyyMMdd_HHmmss.log Version, commit and start date information are displayed in logs at the begining. Injecting commit version from Makefile. Moving DESKTOP_VERSION const to constants.nim Fix #3611
2022-03-24 11:51:24 +00:00
GIT_COMMIT=`git log --pretty=format:'%h' -n 1`
NIM_PARAMS += -d:GIT_COMMIT="$(GIT_COMMIT)"
feat: output messages to csv
2022-06-30 15:11:40 +00:00
OUTPUT_CSV ?= false
ifeq ($(OUTPUT_CSV), true)
NIM_PARAMS += -d:output_csv
$(shell touch .update.timestamp)
endif
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
-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
chores(@general): remove status-lib deps
2022-02-03 14:23:51 +00:00
STATUSGO := vendor/status-go/build/bin/libstatus.$(LIBSTATUS_EXT)
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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"
chores(@general): remove status-lib deps
2022-02-03 14:23:51 +00:00
+ 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(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
STATUSKEYCARDGO := vendor/status-keycard-go/build/libkeycard/libkeycard.$(LIBSTATUS_EXT)
STATUSKEYCARDGO_LIBDIR := $(shell pwd)/$(shell dirname "$(STATUSKEYCARDGO)")
export STATUSKEYCARDGO_LIBDIR
add keycard-go to makefile
2021-09-28 08:06:19 +00:00
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
status-keycard-go: $(STATUSKEYCARDGO)
$(STATUSKEYCARDGO): | deps
echo -e $(BUILD_MSG) "status-keycard-go"
+ cd vendor/status-keycard-go && \
$(MAKE) build-lib $(HANDLE_OUTPUT)
add keycard-go to makefile
2021-09-28 08:06:19 +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
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
# When modifying files that are not tracked in UI_SOURCES (see below),
# e.g. ui/shared/img/*.svg, REBUILD_UI=true can be supplied to `make` to ensure
# a rebuild of resources.rcc: `make REBUILD_UI=true run`
REBUILD_UI ?= false
ifeq ($(REBUILD_UI),true)
$(shell touch ui/main.qml)
endif
chore: improve Makefile targets nim_status_client and rcc Allow for `make` to check the timestamps of files relevant to those targets and thereby skip one or both targets if nothing's changed.
2021-09-16 21:17:10 +00:00
ifeq ($(detected_OS),Darwin)
UI_SOURCES := $(shell find -E ui -type f -iregex '.*(qmldir|qml|qrc)$$' -not -iname 'resources.qrc')
else
UI_SOURCES := $(shell find ui -type f -regextype egrep -iregex '.*(qmldir|qml|qrc)$$' -not -iname 'resources.qrc')
endif
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
UI_RESOURCES := resources.rcc
chore: improve Makefile targets nim_status_client and rcc Allow for `make` to check the timestamps of files relevant to those targets and thereby skip one or both targets if nothing's changed.
2021-09-16 21:17:10 +00:00
$(UI_RESOURCES): $(UI_SOURCES)
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
chore: improve Makefile targets nim_status_client and rcc Allow for `make` to check the timestamps of files relevant to those targets and thereby skip one or both targets if nothing's changed.
2021-09-16 21:17:10 +00:00
rcc: $(UI_RESOURCES)
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
TS_SOURCES := $(shell find ui/i18n -iname '*.ts') # ui/i18n/qml_*.ts
QM_BINARIES := $(shell find ui/i18n -iname "*.ts" | sed 's/\.ts/\.qm/' | sed 's/ui/bin/') # bin/i18n/qml_*.qm
$(QM_BINARIES): TS_FILE = $(shell echo $@ | sed 's/\.qm/\.ts/' | sed 's/bin/ui/')
$(QM_BINARIES): $(TS_SOURCES)
mkdir -p bin/i18n
lrelease -removeidentical $(TS_FILE) -qm $@
compile-translations: $(QM_BINARIES)
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(@wallet): Add opensea api key
2022-02-10 13:22:41 +00:00
DEFAULT_OPENSEA_API_KEY := ""
OPENSEA_API_KEY ?= $(DEFAULT_OPENSEA_API_KEY)
NIM_PARAMS += -d:OPENSEA_API_KEY:"$(OPENSEA_API_KEY)"
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)"
feat: display logs in node management section
2021-09-14 19:39:29 +00:00
NIM_PARAMS += -d:chronicles_sinks=textlines[stdout],textlines[nocolors,dynamic],textlines[file,nocolors] -d:chronicles_runtime_filtering=on -d:chronicles_default_output_device=dynamic
chore: add chronicles configuration to output logs to a file
2021-06-29 18:42:18 +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
RESOURCES_LAYOUT := -d:development
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
# When modifying files that are not tracked in NIM_SOURCES (see below),
# e.g. vendor/*.nim, REBUILD_NIM=true can be supplied to `make` to ensure a
# rebuild of bin/nim_status_client: `make REBUILD_NIM=true run`
# Note: it is not necessary to supply REBUILD_NIM=true after `make update`
# because that target bumps .update.timestamp
REBUILD_NIM ?= false
ifeq ($(REBUILD_NIM),true)
$(shell touch .update.timestamp)
endif
.update.timestamp:
touch .update.timestamp
NIM_SOURCES := .update.timestamp $(shell find src -type f)
chore: improve Makefile targets nim_status_client and rcc Allow for `make` to check the timestamps of files relevant to those targets and thereby skip one or both targets if nothing's changed.
2021-09-16 21:17:10 +00:00
ifeq ($(detected_OS),Windows)
NIM_STATUS_CLIENT := bin/nim_status_client.exe
else
NIM_STATUS_CLIENT := bin/nim_status_client
endif
$(NIM_STATUS_CLIENT): NIM_PARAMS += $(RESOURCES_LAYOUT)
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
$(NIM_STATUS_CLIENT): $(NIM_SOURCES) $(DOTHERSIDE) | $(STATUSGO) $(STATUSKEYCARDGO) $(QRCODEGEN) $(FLEETS) rcc $(QM_BINARIES) deps
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
echo -e $(BUILD_MSG) "$@" && \
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
$(ENV_SCRIPT) nim c $(NIM_PARAMS) --passL:"-L$(STATUSGO_LIBDIR)" --passL:"-lstatus" --passL:"-L$(STATUSKEYCARDGO_LIBDIR)" --passL:"-lkeycard" $(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 \
try to fix macos linking
2021-10-06 11:36:55 +00:00
bin/nim_status_client && \
install_name_tool -change \
libkeycard.dylib \
@rpath/libkeycard.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)
chore: install fileicon on make
2022-09-14 15:44:15 +00:00
ifeq ($(detected_OS),Darwin)
ifeq ("$(wildcard ./node_modules/.bin/fileicon)","")
echo -e "\e[92mInstalling:\e[39m fileicon"
npm i
endif
endif
AppImg packaging
2020-05-14 20:19:01 +00:00
feat(general): Force rebuild of status go at least once a day fixes #4297
2021-12-15 09:13:06 +00:00
nim_status_client: force-rebuild-status-go $(NIM_STATUS_CLIENT)
chore: improve Makefile targets nim_status_client and rcc Allow for `make` to check the timestamps of files relevant to those targets and thereby skip one or both targets if nothing's changed.
2021-09-16 21:17:10 +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
ci: add scripts/sign-linux-tarball.sh for GPG signing Adds `scripts/sign-linux-file.sh` which expectes the following variables set: * `LINUX_GPG_PRIVATE_KEY_FILE` - Path to the GPG export of private key. * `LINUX_GPG_PRIVATE_KEY_PASS` - Password necessary to use the private key. Given a file it creates a file with a `.asc` suffix containing the signature: ``` > wget -q https://status-im-prs.ams3.digitaloceanspaces.com/StatusIm-210809-104514-156806-pr.tar.gz > tar xvf StatusIm-210809-104514-156806-pr.tar.gz StatusIm-210809-104514-156806-pr.AppImage StatusIm-210809-104514-156806-pr.AppImage.asc > gpg --verify StatusIm-210809-104514-156806-pr.AppImage.asc gpg: assuming signed data in 'StatusIm-210809-104514-156806-pr.AppImage' gpg: Signature made Mon 09 Aug 2021 12:54:49 PM CEST using RSA key ID E20B4DFD gpg: Good signature from "Status.im Devel Signing (GPG key for signing Status.im development builds.) <devel@status.im>" [ultimate] Primary key fingerprint: BBF0 5F92 536B ED19 30A9 FD44 009F B3BF E20B 4DFD ``` Issue: https://github.com/status-im/infra-ci/issues/25 Requires: https://github.com/status-im/status-jenkins-lib/pull/32 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-08-04 15:41:31 +00:00
wget -nv https://github.com/AppImage/AppImageKit/releases/download/continuous/$(_APPIMAGE_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
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
ci: add scripts/sign-linux-tarball.sh for GPG signing Adds `scripts/sign-linux-file.sh` which expectes the following variables set: * `LINUX_GPG_PRIVATE_KEY_FILE` - Path to the GPG export of private key. * `LINUX_GPG_PRIVATE_KEY_PASS` - Password necessary to use the private key. Given a file it creates a file with a `.asc` suffix containing the signature: ``` > wget -q https://status-im-prs.ams3.digitaloceanspaces.com/StatusIm-210809-104514-156806-pr.tar.gz > tar xvf StatusIm-210809-104514-156806-pr.tar.gz StatusIm-210809-104514-156806-pr.AppImage StatusIm-210809-104514-156806-pr.AppImage.asc > gpg --verify StatusIm-210809-104514-156806-pr.AppImage.asc gpg: assuming signed data in 'StatusIm-210809-104514-156806-pr.AppImage' gpg: Signature made Mon 09 Aug 2021 12:54:49 PM CEST using RSA key ID E20B4DFD gpg: Good signature from "Status.im Devel Signing (GPG key for signing Status.im development builds.) <devel@status.im>" [ultimate] Primary key fingerprint: BBF0 5F92 536B ED19 30A9 FD44 009F B3BF E20B 4DFD ``` Issue: https://github.com/status-im/infra-ci/issues/25 Requires: https://github.com/status-im/status-jenkins-lib/pull/32 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-08-04 15:41:31 +00:00
STATUS_CLIENT_TARBALL_FULL ?= $(shell realpath $(STATUS_CLIENT_TARBALL))
AppImg packaging
2020-05-14 20:19:01 +00:00
fix(@desktop/input): deploy Qt plugin to support fcitx Qt provides support for various input methods through plugins. Since the fcitx plugin is not delivered with Qt, it needs to be built and deployed by us. Fixes: #4436
2022-01-20 23:28:31 +00:00
ifeq ($(detected_OS),Linux)
FCITX5_QT := vendor/fcitx5-qt/build/qt5/platforminputcontext/libfcitx5platforminputcontextplugin.so
FCITX5_QT_CMAKE_PARAMS := -DCMAKE_BUILD_TYPE=Release -DBUILD_ONLY_PLUGIN=ON -DENABLE_QT4=OFF -DENABLE_QT5=ON
FCITX5_QT_BUILD_CMD := cmake --build . --config Release $(HANDLE_OUTPUT)
endif
$(FCITX5_QT): | deps
echo -e $(BUILD_MSG) "fcitx5-qt"
+ cd vendor/fcitx5-qt && \
mkdir -p build && \
cd build && \
rm -f CMakeCache.txt && \
cmake $(FCITX5_QT_CMAKE_PARAMS) \
.. $(HANDLE_OUTPUT) && \
$(FCITX5_QT_BUILD_CMD)
fix: logs on node tab
2022-07-01 14:59:25 +00:00
PRODUCTION_PARAMETERS := -d:production -d:chronicles_sinks=textlines[stdout],textlines[nocolors,dynamic]
feature(desktop/general): Configurable logs Log level can be chosen during application startup. Logs are disabled for production build. Fix #3609
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_APPIMAGE): override RESOURCES_LAYOUT := $(PRODUCTION_PARAMETERS)
fix(@desktop/input): deploy Qt plugin to support fcitx Qt provides support for various input methods through plugins. Since the fcitx plugin is not delivered with Qt, it needs to be built and deployed by us. Fixes: #4436
2022-01-20 23:28:31 +00:00
$(STATUS_CLIENT_APPIMAGE): nim_status_client $(APPIMAGE_TOOL) nim-status.desktop $(FCITX5_QT)
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
feat(spellchecking): add dictionaries as submodule Closes: #3449
2021-09-16 15:48:25 +00:00
mkdir -p tmp/linux/dist/usr/bin/dictionaries
cp -R spellchecking/dictionaries tmp/linux/dist/usr/bin/dictionaries
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 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
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
cp bin/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/
chores(@general): remove status-lib deps
2022-02-03 14:23:51 +00:00
cp vendor/status-go/build/bin/libstatus.so tmp/linux/dist/usr/lib/
cp vendor/status-go/build/bin/libstatus.so.0 tmp/linux/dist/usr/lib/
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
cp $(STATUSKEYCARDGO) tmp/linux/dist/usr/lib/
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
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
fix(@desktop/input): deploy Qt plugin to support fcitx Qt provides support for various input methods through plugins. Since the fcitx plugin is not delivered with Qt, it needs to be built and deployed by us. Fixes: #4436
2022-01-20 23:28:31 +00:00
# Qt plugins
cp $(FCITX5_QT) tmp/linux/dist/usr/plugins/platforminputcontexts/
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)
ci: add scripts/sign-linux-tarball.sh for GPG signing Adds `scripts/sign-linux-file.sh` which expectes the following variables set: * `LINUX_GPG_PRIVATE_KEY_FILE` - Path to the GPG export of private key. * `LINUX_GPG_PRIVATE_KEY_PASS` - Password necessary to use the private key. Given a file it creates a file with a `.asc` suffix containing the signature: ``` > wget -q https://status-im-prs.ams3.digitaloceanspaces.com/StatusIm-210809-104514-156806-pr.tar.gz > tar xvf StatusIm-210809-104514-156806-pr.tar.gz StatusIm-210809-104514-156806-pr.AppImage StatusIm-210809-104514-156806-pr.AppImage.asc > gpg --verify StatusIm-210809-104514-156806-pr.AppImage.asc gpg: assuming signed data in 'StatusIm-210809-104514-156806-pr.AppImage' gpg: Signature made Mon 09 Aug 2021 12:54:49 PM CEST using RSA key ID E20B4DFD gpg: Good signature from "Status.im Devel Signing (GPG key for signing Status.im development builds.) <devel@status.im>" [ultimate] Primary key fingerprint: BBF0 5F92 536B ED19 30A9 FD44 009F B3BF E20B 4DFD ``` Issue: https://github.com/status-im/infra-ci/issues/25 Requires: https://github.com/status-im/status-jenkins-lib/pull/32 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-08-04 15:41:31 +00:00
# if LINUX_GPG_PRIVATE_KEY_FILE is not set then we don't generate a signature
ifdef LINUX_GPG_PRIVATE_KEY_FILE
scripts/sign-linux-file.sh $(STATUS_CLIENT_APPIMAGE)
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: 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)
ci: add scripts/sign-linux-tarball.sh for GPG signing Adds `scripts/sign-linux-file.sh` which expectes the following variables set: * `LINUX_GPG_PRIVATE_KEY_FILE` - Path to the GPG export of private key. * `LINUX_GPG_PRIVATE_KEY_PASS` - Password necessary to use the private key. Given a file it creates a file with a `.asc` suffix containing the signature: ``` > wget -q https://status-im-prs.ams3.digitaloceanspaces.com/StatusIm-210809-104514-156806-pr.tar.gz > tar xvf StatusIm-210809-104514-156806-pr.tar.gz StatusIm-210809-104514-156806-pr.AppImage StatusIm-210809-104514-156806-pr.AppImage.asc > gpg --verify StatusIm-210809-104514-156806-pr.AppImage.asc gpg: assuming signed data in 'StatusIm-210809-104514-156806-pr.AppImage' gpg: Signature made Mon 09 Aug 2021 12:54:49 PM CEST using RSA key ID E20B4DFD gpg: Good signature from "Status.im Devel Signing (GPG key for signing Status.im development builds.) <devel@status.im>" [ultimate] Primary key fingerprint: BBF0 5F92 536B ED19 30A9 FD44 009F B3BF E20B 4DFD ``` Issue: https://github.com/status-im/infra-ci/issues/25 Requires: https://github.com/status-im/status-jenkins-lib/pull/32 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-08-04 15:41:31 +00:00
cd $(shell dirname $(STATUS_CLIENT_APPIMAGE)) && \
tar czvf $(STATUS_CLIENT_TARBALL_FULL) --ignore-failed-read \
$(shell basename $(STATUS_CLIENT_APPIMAGE)){,.asc}
ifdef LINUX_GPG_PRIVATE_KEY_FILE
scripts/sign-linux-file.sh $(STATUS_CLIENT_TARBALL)
endif
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
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
feature(desktop/general): Configurable logs Log level can be chosen during application startup. Logs are disabled for production build. Fix #3609
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_DMG): override RESOURCES_LAYOUT := $(PRODUCTION_PARAMETERS)
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/
feat(spellchecking): add dictionaries as submodule Closes: #3449
2021-09-16 15:48:25 +00:00
cp -R spellchecking/dictionaries $(MACOS_OUTER_BUNDLE)/Contents/MacOS/dictionaries
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
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
cp bin/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
Added ENV: STATUS_CLIENT_7Z
2021-09-15 08:31:45 +00:00
STATUS_CLIENT_7Z ?= pkg/Status.7z
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
feature(desktop/general): Configurable logs Log level can be chosen during application startup. Logs are disabled for production build. Fix #3609
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_EXE): override RESOURCES_LAYOUT := $(PRODUCTION_PARAMETERS)
feat(widnows-installer): Add compilation windows installer build step Closes: #2223
2021-07-15 11:12:18 +00:00
$(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/
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
cp bin/i18n/* $(OUTPUT)/resources/i18n
fix(@desktop/windows): installer to include cacert.pem
2021-09-03 03:16:27 +00:00
cp cacert.pem $(OUTPUT)/bin/cacert.pem
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
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
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
cp $(DOTHERSIDE) $(STATUSGO) $(STATUSKEYCARDGO) tmp/windows/tools/*.dll $(OUTPUT)/bin/
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
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
Testing changes suggested in PR
2021-09-15 14:08:13 +00:00
$(STATUS_CLIENT_7Z): OUTPUT := tmp/windows/dist/Status
$(STATUS_CLIENT_7Z): $(STATUS_CLIENT_EXE)
feat(@desktop/windows): produce 7z archive when packaging
2021-09-15 07:44:36 +00:00
echo -e $(BUILD_MSG) "7z"
Fixed output archive path
2021-09-15 08:50:19 +00:00
7z a $(STATUS_CLIENT_7Z) ./$(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
fix(Makefile): ensure `pkg` target rebuilds status client Otherwise `make pkg` would deploy already built status client, regardless of its initial configuration. `make clean` is not required before `make pkg` anymore. fixes: #6241
2022-06-27 18:49:49 +00:00
# pkg target rebuilds status client
# this is to ensure production version of the app is deployed
pkg:
rm $(NIM_STATUS_CLIENT) | :
$(MAKE) $(PKG_TARGET)
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
build: implement packaging steps for the Windows build Implement a `pkg-windows` target that ultimately results in `Status.zip` being written to `pkg/`. Note: this commit does not introduce code signing for the Windows build since that piece is still a work in progress. `pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of [`windeployqt`][windeployqt], which copies the needed portions of Qt into the folder. Since DLL resolution is relatively inflexible, a launcher `Status.exe` is created at the top-level of the folder; the launcher opens `bin/Status.exe` while adding the portable folder's `bin/` to the `PATH`, allowing `bin/Status.exe` to resolve the DLLs in that folder. A few additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * 7-zip * dos2unix (provides unix2dos) * findutils * go * rcedit * wget The above list builds on the tools list in PR #521, and the other requirements and instructions in that PR's description still apply. **Why not build an installer?** When starting work on packaging for the Windows build, my initial plan was to build an installer, and for that purpose I researched the [WiX Toolset][wix], the [Qt Installer Framework][qtif], and some other options. I found that building an installer is a bit complex. I then recalled, from personal experience, that [Cmder][cmder]'s [Mini download][mini] is installer-less. You simply unzip the download and place the `cmder_mini` folder wherever you prefer. Such an approach was also recommended to me in one of the Nim language's community chats. In addition to being simpler, the installer-less approach also gives installation of Status Desktop a lower profile than an installer-application would since nothing is written to the Windows registry, added to the *Add or remove programs* list, etc. I think that's a benefit given the privacy-security focus of Status, but others may feel differently so please provide feedback on this point! [windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html [scoop]: https://scoop.sh/ [wix]: https://wixtoolset.org/ [qtif]: https://doc.qt.io/qtinstallerframework/index.html [cmder]: https://cmder.net/ [mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
pkg-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
Testing changes suggested in PR
2021-09-15 14:08:13 +00:00
zip-windows: check-pkg-target-windows $(STATUS_CLIENT_7Z)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
clean: | clean-common
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
rm -rf bin/* node_modules bottles/* pkg/* tmp/* $(STATUSGO) $(STATUSKEYCARDGO)
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
feat(general): Force rebuild of status go at least once a day fixes #4297
2021-12-15 09:13:06 +00:00
force-rebuild-status-go:
bash ./scripts/force-rebuild-status-go.sh $(STATUSGO)
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
run: $(RUN_TARGET)
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: 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
chore(dev): add STATUS_PORT env var forwarding to status-go
2022-09-22 17:08:24 +00:00
# Will only work at password login. Keycard login doesn't forward the configuration
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_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
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
run-linux: nim_status_client
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
echo -e "\e[92mRunning:\e[39m bin/nim_status_client"
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
LD_LIBRARY_PATH="$(QT5_LIBDIR)":"$(STATUSGO_LIBDIR)":"$(STATUSKEYCARDGO_LIBDIR)" \
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
./bin/nim_status_client
chore: install fileicon on make
2022-09-14 15:44:15 +00:00
run-macos: nim_status_client
build: modify run logic for macOS dev builds so notifications work
2021-04-30 18:58:55 +00:00
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 ./
chore: remove npx
2022-09-14 19:47:19 +00:00
./node_modules/.bin/fileicon set bin/nim_status_client status-dev.icns
build: modify run logic for macOS dev builds so notifications work
2021-04-30 18:58:55 +00:00
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
fix: ensure Nim recompile after make update These changes are a follow-up to #3582. Also support `REBUILD_NIM=true` and `REBUILD_UI=true` variables so that it's possible to ensure a rebuild for the next invocation of `make` or `make run`. Dev docs have been updated: https://hackmd.io/OtFjDnH6QtOl3K65fKKEGg Also adjust run targets so that e.g. `make -j16 run` works correctly. Closes #3639.
2021-09-21 16:28:25 +00:00
run-windows: nim_status_client $(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"
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
PATH="$(shell pwd)"/"$(shell dirname "$(DOTHERSIDE)")":"$(STATUSGO_LIBDIR)":"$(STATUSKEYCARDGO_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