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

815 lines
27 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 \
Makefile: move QT dir check to separate target This way we avoid errors about missing QT when calling targets that do not require it, like `make clean` or `make deps`. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-08 09:11:53 +00:00
check-qt-dir \
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 \
feat: introduce nim tests
2022-12-19 18:55:40 +00:00
tests-nim-linux \
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 \
ci: improve clean-git by reseting submodules This avoids a situation in which `variables.mk` from `nimbus-build-system` does't exist, but at the same time `git submodule update` doesn't work due to sumodules stuck in a bad state. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-21 16:23:32 +00:00
statusq-sanity-checker \
run-statusq-sanity-checker \
general: Add possibility to build/run StatusQ tests via make
2023-09-05 13:46:29 +00:00
statusq-tests \
run-statusq-tests \
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
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
QMAKE_PATH := $(shell which qmake);
QT_ARCH := $(shell lipo -archs $(QMAKE_PATH))
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
Makefile: move QT dir check to separate target This way we avoid errors about missing QT when calling targets that do not require it, like `make clean` or `make deps`. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-08 09:11:53 +00:00
check-qt-dir:
fix: build issue caused by pkgconfig and system-wide QT. Avoid using QTDIR env and hardcoded subdirectories. Use 'qmake' to detect paths to lib, qml, etc. It fixes build on hosts with multiple QT installations, where one of them is installed system-wide.
2022-12-26 09:22:25 +00:00
ifeq ($(shell qmake -v 2>/dev/null),)
$(error Cannot find your Qt5 installation. Please make sure to export correct Qt installation binaries path to PATH env)
Makefile: move QT dir check to separate target This way we avoid errors about missing QT when calling targets that do not require it, like `make clean` or `make deps`. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-08 09:11:53 +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(hunspell): Remove hunspell usage in DOtherSide
2022-12-09 10:26:02 +00:00
BOTTLES := $(addprefix $(BOTTLES_DIR)/,openssl@1.1 pcre)
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
ifeq ($(QT_ARCH),arm64)
EXCLUDE_BOTTLES := 'linux'
else
EXCLUDE_BOTTLES := 'arm|linux'
endif
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)
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
echo -e "\033[92mFetching:\033[39m $(notdir $@) bottle arch $(QT_ARCH)"
./scripts/fetch-brew-bottle.sh $(notdir $@) $(EXCLUDE_BOTTLES)
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):
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mUpdating:\033[39m macOS Homebrew"
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
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
makefile: avoid rebuilds by using order-only deps By using the pipe(`|`) operator which indicates order-only dependencies we can avoid unnecessary rebuilds triggered by additon of QT dir check: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-14 12:00:39 +00:00
deps: | check-qt-dir deps-common bottles
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
makefile: avoid rebuilds by using order-only deps By using the pipe(`|`) operator which indicates order-only dependencies we can avoid unnecessary rebuilds triggered by additon of QT dir check: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-14 12:00:39 +00:00
update: | check-qt-dir 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)
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_BUILD_TYPE=Debug
DOTHERSIDE_CMAKE_CONFIG_PARAMS := -DQML_DEBUG_PORT=$(QML_DEBUG_PORT)
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
else
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_BUILD_TYPE=Release
feat(Makefile): add QML_DEBUG and QML_DEBUG_PORT options closes: #6973
2022-08-11 09:14:22 +00:00
endif
feat(general): Initial setup for app monitoring tool Closes: #8786
2023-01-04 16:05:07 +00:00
MONITORING ?= false
ifneq ($(MONITORING), false)
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
DOTHERSIDE_CMAKE_CONFIG_PARAMS += -DMONITORING:BOOL=ON -DMONITORING_QML_ENTRY_POINT:STRING="/../monitoring/Main.qml"
feat(general): Initial setup for app monitoring tool Closes: #8786
2023-01-04 16:05:07 +00:00
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)
makefile: fix MacOS builds, restore missing env vars For some reason the an infra change has triggered the behavior of `make` where the `if` clauses that compares `QT5_PKGCONFIG_INSTALL_PREFIX` with `QT5_INSTALL_PREFIX` would be true, which would cause `QT5_LIBDIR` to not be exported, and some `NIM_PARAMS` to not be set at all. Resolves: https://github.com/status-im/status-desktop/issues/10876 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2023-06-02 09:28:18 +00:00
export QT5_LIBDIR := $(shell qmake -query QT_INSTALL_LIBS 2>/dev/null)
fix: build issue caused by pkgconfig and system-wide QT. Avoid using QTDIR env and hardcoded subdirectories. Use 'qmake' to detect paths to lib, qml, etc. It fixes build on hosts with multiple QT installations, where one of them is installed system-wide.
2022-12-26 09:22:25 +00:00
QT5_QMLDIR := $(shell qmake -query QT_INSTALL_QML 2>/dev/null)
QT5_INSTALL_PREFIX := $(shell qmake -query QT_INSTALL_PREFIX 2>/dev/null)
QT5_PKGCONFIG_INSTALL_PREFIX := $(shell pkg-config --variable=prefix Qt5Core 2>/dev/null)
ifeq ($(QT5_INSTALL_PREFIX),$(QT5_PKGCONFIG_INSTALL_PREFIX))
QT5_PCFILEDIR := $(shell pkg-config --variable=pcfiledir Qt5Core 2>/dev/null)
else
QT5_PCFILEDIR := $(QT5_LIBDIR)/pkgconfig
makefile: fix MacOS builds, restore missing env vars For some reason the an infra change has triggered the behavior of `make` where the `if` clauses that compares `QT5_PKGCONFIG_INSTALL_PREFIX` with `QT5_INSTALL_PREFIX` would be true, which would cause `QT5_LIBDIR` to not be exported, and some `NIM_PARAMS` to not be set at all. Resolves: https://github.com/status-im/status-desktop/issues/10876 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2023-06-02 09:28:18 +00:00
endif
# some manually installed Qt5 instances have wrong paths in their *.pc files, so we pass the right one to the linker here
ifeq ($(detected_OS),Darwin)
NIM_PARAMS += -L:"-framework Foundation -framework AppKit -framework Security -framework IOKit -framework CoreServices -framework LocalAuthentication"
# 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)"
else
NIM_PARAMS += --passL:"-L$(QT5_LIBDIR)"
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
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
DOTHERSIDE_LIBFILE := vendor/DOtherSide/build/lib/libDOtherSideStatic.a
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"
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
NIM_PARAMS += --passL:"$(DOTHERSIDE_LIBFILE)" --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
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
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
ifeq ($(detected_OS),Windows)
COMMON_CMAKE_CONFIG_PARAMS := -T"v141" -A x64
endif
crosscompile to amd64 when building on darwin/arm64
2021-09-23 13:38:38 +00:00
ifeq ($(detected_OS),Darwin)
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
ifeq ("$(shell sysctl -nq hw.optional.arm64)","1")
ifneq ($(QT_ARCH),arm64)
STATUSGO_MAKE_PARAMS += GOBIN_SHARED_LIB_CFLAGS="CGO_ENABLED=1 GOOS=darwin GOARCH=amd64"
STATUSKEYCARDGO_MAKE_PARAMS += CGOFLAGS="CGO_ENABLED=1 GOOS=darwin GOARCH=amd64"
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_CONFIG_PARAMS += -DCMAKE_OSX_ARCHITECTURES=x86_64
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
QRCODEGEN_MAKE_PARAMS += CFLAGS="-target x86_64-apple-macos10.12"
crosscompile to amd64 when building on darwin/arm64
2021-09-23 13:38:38 +00:00
NIM_PARAMS += --cpu:amd64 --os:MacOSX --passL:"-arch x86_64" --passC:"-arch x86_64"
endif
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
endif
crosscompile to amd64 when building on darwin/arm64
2021-09-23 13:38:38 +00:00
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
chore(enableStatusGoOptimizations): Optimise Release build with O3 CFLAG
2023-06-02 12:30:11 +00:00
STATUSGO_MAKE_PARAMS += CGO_CFLAGS="-O3"
STATUSKEYCARDGO_MAKE_PARAMS += CGO_CFLAGS="-O3"
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
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
feat: Add status-go version to About screen - Settings/About now displays the `status-go` version, read from its `VERSION` file - use the actual app icon, to differentiate between prod/dev version - make the version numbers clickable, taking the user to either the release notes (prod) or the GH commit browser (dev) - add "Is production" switch to the About page in storybook Closes #11424
2023-07-26 14:34:21 +00:00
SGVERSIONFILE=vendor/status-go/VERSION
feat: Version Updating Fixes #1290
2021-06-17 18:41:11 +00:00
DESKTOP_VERSION=`cat $(VERSIONFILE)`
feat: Add status-go version to About screen - Settings/About now displays the `status-go` version, read from its `VERSION` file - use the actual app icon, to differentiate between prod/dev version - make the version numbers clickable, taking the user to either the release notes (prod) or the GH commit browser (dev) - add "Is production" switch to the About page in storybook Closes #11424
2023-07-26 14:34:21 +00:00
STATUSGO_VERSION=`cat $(SGVERSIONFILE)`
feat: Version Updating Fixes #1290
2021-06-17 18:41:11 +00:00
NIM_PARAMS += -d:DESKTOP_VERSION="$(DESKTOP_VERSION)"
feat: Add status-go version to About screen - Settings/About now displays the `status-go` version, read from its `VERSION` file - use the actual app icon, to differentiate between prod/dev version - make the version numbers clickable, taking the user to either the release notes (prod) or the GH commit browser (dev) - add "Is production" switch to the About page in storybook Closes #11424
2023-07-26 14:34:21 +00:00
NIM_PARAMS += -d:STATUSGO_VERSION="$(STATUSGO_VERSION)"
feat: Version Updating Fixes #1290
2021-06-17 18:41:11 +00:00
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
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
##
## StatusQ
##
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
STATUSQ_SOURCE_PATH := ui/StatusQ
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
STATUSQ_BUILD_PATH := ui/StatusQ/build
STATUSQ_INSTALL_PATH := $(shell pwd)/bin
STATUSQ_CMAKE_CACHE := $(STATUSQ_BUILD_PATH)/CMakeCache.txt
$(STATUSQ_CMAKE_CACHE): | deps
echo -e "\033[92mConfiguring:\033[39m StatusQ"
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
cmake \
-DCMAKE_INSTALL_PREFIX=$(STATUSQ_INSTALL_PATH) \
-DCMAKE_BUILD_TYPE=$(COMMON_CMAKE_BUILD_TYPE) \
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
-DSTATUSQ_BUILD_SANDBOX=OFF \
-DSTATUSQ_BUILD_SANITY_CHECKER=OFF \
-DSTATUSQ_BUILD_TESTS=OFF \
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
$(COMMON_CMAKE_CONFIG_PARAMS) \
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
-B $(STATUSQ_BUILD_PATH) \
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
-S $(STATUSQ_SOURCE_PATH) \
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
-Wno-dev \
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
$(HANDLE_OUTPUT)
feat(@desktop/keycards): managing mocked keycards when running keycard flows
2023-09-22 10:38:44 +00:00
statusq-configure: | $(STATUSQ_CMAKE_CACHE)
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
statusq-build: | statusq-configure
echo -e "\033[92mBuilding:\033[39m StatusQ"
cmake --build $(STATUSQ_BUILD_PATH) \
--target StatusQ \
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
--config $(COMMON_CMAKE_BUILD_TYPE) \
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
$(HANDLE_OUTPUT)
statusq-install: | statusq-build
echo -e "\033[92mInstalling:\033[39m StatusQ"
cmake --install $(STATUSQ_BUILD_PATH) \
$(HANDLE_OUTPUT)
statusq: | statusq-install
statusq-clean:
echo -e "\033[92mCleaning:\033[39m StatusQ"
rm -rf $(STATUSQ_BUILD_PATH)
rm -rf $(STATUSQ_INSTALL_PATH)/StatusQ
statusq-sanity-checker:
echo -e "\033[92mConfiguring:\033[39m StatusQ SanityChecker"
cmake \
-DSTATUSQ_BUILD_SANDBOX=OFF \
-DSTATUSQ_BUILD_SANITY_CHECKER=ON \
-DSTATUSQ_BUILD_TESTS=OFF \
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
-B $(STATUSQ_BUILD_PATH) \
-S $(STATUSQ_SOURCE_PATH) \
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
$(HANDLE_OUTPUT)
echo -e "\033[92mBuilding:\033[39m StatusQ SanityChecker"
cmake \
--build $(STATUSQ_BUILD_PATH) \
--target SanityChecker \
$(HANDLE_OUTPUT)
run-statusq-sanity-checker: statusq-sanity-checker
echo -e "\033[92mRunning:\033[39m StatusQ SanityChecker"
$(STATUSQ_BUILD_PATH)/bin/SanityChecker
general: Add possibility to build/run StatusQ tests via make
2023-09-05 13:46:29 +00:00
statusq-tests:
echo -e "\033[92mConfiguring:\033[39m StatusQ Unit Tests"
cmake \
-DSTATUSQ_BUILD_SANDBOX=OFF \
-DSTATUSQ_BUILD_SANITY_CHECKER=OFF \
-DSTATUSQ_BUILD_TESTS=ON \
-B $(STATUSQ_BUILD_PATH) \
-S $(STATUSQ_SOURCE_PATH) \
$(HANDLE_OUTPUT)
echo -e "\033[92mBuilding:\033[39m StatusQ Unit Tests"
cmake \
--build $(STATUSQ_BUILD_PATH) \
--target TestStatusQ \
$(HANDLE_OUTPUT)
run-statusq-tests: statusq-tests
echo -e "\033[92mRunning:\033[39m StatusQ Unit Tests"
$(STATUSQ_BUILD_PATH)/bin/TestStatusQ
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
##
## DOtherSide
##
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
ifneq ($(detected_OS),Windows)
DOTHERSIDE_CMAKE_CONFIG_PARAMS += -DENABLE_DYNAMIC_LIBS=OFF -DENABLE_STATIC_LIBS=ON
feat(@desktop/keycards): managing mocked keycards when running keycard flows
2023-09-22 10:38:44 +00:00
# NIM_PARAMS +=
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
else
DOTHERSIDE_LIBFILE := vendor/DOtherSide/build/lib/$(COMMON_CMAKE_BUILD_TYPE)/DOtherSide.dll
DOTHERSIDE_CMAKE_CONFIG_PARAMS += -DENABLE_DYNAMIC_LIBS=ON -DENABLE_STATIC_LIBS=OFF
NIM_PARAMS += -L:$(DOTHERSIDE_LIBFILE)
endif
DOTHERSIDE_SOURCE_PATH := vendor/DOtherSide
DOTHERSIDE_BUILD_PATH := vendor/DOtherSide/build
DOTHERSIDE_CMAKE_CACHE := $(DOTHERSIDE_BUILD_PATH)/CMakeCache.txt
DOTHERSIDE_LIBDIR := $(shell pwd)/$(shell dirname "$(DOTHERSIDE_LIBFILE)")
export DOTHERSIDE_LIBDIR
$(DOTHERSIDE_CMAKE_CACHE): | deps
echo -e "\033[92mConfiguring:\033[39m DOtherSide"
cmake \
-DCMAKE_BUILD_TYPE=$(COMMON_CMAKE_BUILD_TYPE) \
-DENABLE_DOCS=OFF \
-DENABLE_TESTS=OFF \
$(COMMON_CMAKE_CONFIG_PARAMS) \
$(DOTHERSIDE_CMAKE_CONFIG_PARAMS) \
-B $(DOTHERSIDE_BUILD_PATH) \
-S $(DOTHERSIDE_SOURCE_PATH) \
-Wno-dev \
$(HANDLE_OUTPUT)
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
feat(@desktop/keycards): managing mocked keycards when running keycard flows
2023-09-22 10:38:44 +00:00
dotherside-configure: | $(DOTHERSIDE_CMAKE_CACHE)
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
dotherside-build: | dotherside-configure
echo -e "\033[92mBuilding:\033[39m DOtherSide"
cmake \
--build $(DOTHERSIDE_BUILD_PATH) \
--config $(COMMON_CMAKE_BUILD_TYPE) \
$(HANDLE_OUTPUT)
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
dotherside-clean:
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
echo -e "\033[92mCleaning:\033[39m DOtherSide"
rm -rf $(DOTHERSIDE_BUILD_PATH)
dotherside: | dotherside-build
##
## status-go
##
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
$(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 && \
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
$(MAKE) statusgo-shared-library $(STATUSGO_MAKE_PARAMS) $(HANDLE_OUTPUT)
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
status-go: $(STATUSGO)
status-go-clean:
echo -e "\033[92mCleaning:\033[39m status-go"
rm -f $(STATUSGO)
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/keycards): managing mocked keycards when running keycard flows
2023-09-22 10:38:44 +00:00
STATUSKEYCARDGO_RULE := build-lib
ifeq ($(TEST_ENVIRONMENT),true)
STATUSKEYCARDGO_RULE := build-mocked-lib
endif
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 && \
feat(@desktop/keycards): managing mocked keycards when running keycard flows
2023-09-22 10:38:44 +00:00
$(MAKE) $(STATUSKEYCARDGO_RULE) $(STATUSKEYCARDGO_MAKE_PARAMS) $(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 && \
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
$(MAKE) $(QRCODEGEN_MAKE_PARAMS) $(HANDLE_OUTPUT)
feat: show qr codes
2020-06-23 17:17:58 +00:00
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
FLEETS_FILE := ./fleets.json
$(FLEETS_FILE):
echo -e $(BUILD_MSG) "Getting latest $(FLEETS_FILE)"
curl -s https://fleets.status.im/ > $(FLEETS_FILE)
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:
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
rm -f $(FLEETS_FILE)
Update docker linux version
2020-11-06 15:50:58 +00:00
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
fleets-update: fleets-remove $(FLEETS_FILE)
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
makefile: avoid rebuilds by using order-only deps By using the pipe(`|`) operator which indicates order-only dependencies we can avoid unnecessary rebuilds triggered by additon of QT dir check: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-14 12:00:39 +00:00
$(UI_RESOURCES): $(UI_SOURCES) | check-qt-dir
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/')
makefile: avoid rebuilds by using order-only deps By using the pipe(`|`) operator which indicates order-only dependencies we can avoid unnecessary rebuilds triggered by additon of QT dir check: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-14 12:00:39 +00:00
$(QM_BINARIES): $(TS_SOURCES) | check-qt-dir
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
mkdir -p bin/i18n
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
lrelease -removeidentical $(TS_FILE) -qm $@ $(HANDLE_OUTPUT)
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
log-compile-translations:
echo -e "\033[92mCompiling:\033[39m translations"
compile-translations: | log-compile-translations $(QM_BINARIES)
chore(translations): add lrealese as part of build process closes: #6418
2022-07-14 16:58:20 +00:00
feat(@wallet): add pokt network + fallbark
2023-02-17 12:21:46 +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 Pokt account and token instead of relying on this default token
# during development
DEFAULT_POKT_TOKEN := 849214fd2f85acead08f5184
POKT_TOKEN ?= $(DEFAULT_POKT_TOKEN)
NIM_PARAMS += -d:POKT_TOKEN:"$(POKT_TOKEN)"
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
feat(@wallet): add pokt network + fallbark
2023-02-17 12:21:46 +00:00
DEFAULT_INFURA_TOKEN := 220a1abb4b6943a093c35d0ce4fb0732
INFURA_TOKEN ?= $(DEFAULT_INFURA_TOKEN)
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
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)"
chore: add KDF_ITERATIONS var to the makefile
2022-08-15 13:46:19 +00:00
# used to override the default number of kdf iterations for sqlcipher
KDF_ITERATIONS ?= 0
ifeq ($(shell test $(KDF_ITERATIONS) -gt 0; echo $$?),0)
NIM_PARAMS += -d:KDF_ITERATIONS:"$(KDF_ITERATIONS)"
endif
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
ci: fix read-only FS errors in AppImage After a LOT of work from @jrainville bisecting the release branch he identified the issue to be this commit: https://github.com/status-im/status-desktop/commit/dad8e453 ci: bump client build retries to 20 Which actually was poorly squashed by @iurimatias and contains the commit that also adds the retries in the first place: https://github.com/status-im/status-desktop/commit/a5ba2537 ci: retry nim_status_client build 3 times The reason why that's an issue is because normally it was caled by `make tgz-linux` target which included this setting: ``` override RESOURCES_LAYOUT := $(PRODUCTION_PARAMETERS) ``` Which caused `NIM_PARAMS` to use `-d:development` instead of `-d:production`. The result was the app trying to write config file changes to the read-only filesystem of the AppImage. Resolves: https://github.com/status-im/status-desktop/issues/11295 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2023-07-05 17:59:57 +00:00
RESOURCES_LAYOUT ?= -d:development
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
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)
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
$(NIM_STATUS_CLIENT): $(NIM_SOURCES) | statusq dotherside check-qt-dir $(STATUSGO) $(STATUSKEYCARDGO) $(QRCODEGEN) $(FLEETS) rcc compile-translations deps
Makefile: refactor nim_status_client target Signed-off-by: Jakub Sokołowski <jakub@status.im>
2023-06-05 11:38:37 +00:00
echo -e $(BUILD_MSG) "$@"
$(ENV_SCRIPT) nim c $(NIM_PARAMS) \
--passL:"-L$(STATUSGO_LIBDIR)" \
--passL:"-lstatus" \
--passL:"-L$(STATUSKEYCARDGO_LIBDIR)" \
--passL:"-lkeycard" \
--passL:"$(QRCODEGEN)" \
--passL:"-lm" \
$(NIM_EXTRA_PARAMS) src/nim_status_client.nim
chore: install fileicon on make
2022-09-14 15:44:15 +00:00
ifeq ($(detected_OS),Darwin)
Makefile: refactor nim_status_client target Signed-off-by: Jakub Sokołowski <jakub@status.im>
2023-06-05 11:38:37 +00:00
install_name_tool -change \
libstatus.dylib \
@rpath/libstatus.dylib \
bin/nim_status_client
install_name_tool -change \
libkeycard.dylib \
@rpath/libkeycard.dylib \
bin/nim_status_client
chore: install fileicon on make
2022-09-14 15:44:15 +00:00
ifeq ("$(wildcard ./node_modules/.bin/fileicon)","")
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mInstalling:\033[39m fileicon"
chore: install fileicon on make
2022-09-14 15:44:15 +00:00
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):
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mFetching:\033[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
makefile: avoid rebuilds by using order-only deps By using the pipe(`|`) operator which indicates order-only dependencies we can avoid unnecessary rebuilds triggered by additon of QT dir check: https://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-14 12:00:39 +00:00
$(FCITX5_QT): | check-qt-dir deps
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
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)
chore: re-enable logging in prod version closes: #8932
2023-01-03 20:17:13 +00:00
PRODUCTION_PARAMETERS := -d:production
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
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/.
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
cp -R $(FLEETS_FILE) 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
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
mkdir -p tmp/linux/dist/usr/bin/StatusQ
cp bin/StatusQ/* tmp/linux/dist/usr/bin/StatusQ
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"
fix: build issue caused by pkgconfig and system-wide QT. Avoid using QTDIR env and hardcoded subdirectories. Use 'qmake' to detect paths to lib, qml, etc. It fixes build on hosts with multiple QT installations, where one of them is installed system-wide.
2022-12-26 09:22:25 +00:00
linuxdeployqt tmp/linux/dist/nim-status.desktop -no-copy-copyright-files -qmldir=ui -qmlimport=$(QT5_QMLDIR) -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):
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mInstalling:\033[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/
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/
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
cp -R $(FLEETS_FILE) $(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
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
mkdir -p $(MACOS_OUTER_BUNDLE)/Contents/MacOS/StatusQ
cp bin/StatusQ/* $(MACOS_OUTER_BUNDLE)/Contents/MacOS/StatusQ
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
fix: Add camera entitlement on MacOS (#11683)
2023-07-27 08:39:43 +00:00
scripts/sign-macos-pkg.sh $(MACOS_OUTER_BUNDLE) $(MACOS_CODESIGN_IDENT) --entitlements Entitlements.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: switch altool to notarytool
2023-08-08 12:06:06 +00:00
notarize-macos: export CHECK_TIMEOUT ?= 10m
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 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):
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mFetching:\033[39m prebuilt DLLs from nim-lang.org"
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/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
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
mkdir -p $(OUTPUT)/bin $(OUTPUT)/resources $(OUTPUT)/vendor $(OUTPUT)/resources/i18n $(OUTPUT)/bin/StatusQ
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
cat windows-install.txt | unix2dos > $(OUTPUT)/INSTALL.txt
fleets.json: drop decomissioned eth.test fleet The fleet wasn't being used so it has been liquidated: https://github.com/status-im/infra-eth-cluster/commit/de986014 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-12-09 07:33:02 +00:00
cp status.ico status.svg resources.rcc $(FLEETS_FILE) $(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
fix(StatusQ): StatusQ is QML module (#10207) * StatusQ QML module * qzxing is static lib again * updated StatusQ resources * fixed Emoji lookup * added display to tests-imports ci
2023-04-14 08:18:56 +00:00
cp bin/StatusQ/* $(OUTPUT)/bin/StatusQ
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
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
cp $(DOTHERSIDE_LIBFILE) $(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)
fix(Makefile): Bugfixes and minor improvements (#10423)
2023-04-25 15:01:19 +00:00
clean: | clean-common statusq-clean status-go-clean dotherside-clean
rm -rf bin/* node_modules bottles/* pkg/* tmp/* $(STATUSKEYCARDGO)
chore: Add Apple silicon support
2023-03-10 10:36:03 +00:00
+ $(MAKE) -C vendor/QR-Code-generator/c/ --no-print-directory clean
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: use git clean instead of cleanWs() function This is a continuation of attempts to fix provlems with Windows CI hosts getting into a broken state due to `.git` directory becoming a file for random submodules for unknown reason. Instead of relying on Jenkins functionality of `cleanWs()` function provided by the [Workspace Cleanup Plugin](https://plugins.jenkins.io/ws-cleanup) we use Git which should be more reliable, and possibly also speed up the initial checkout of the repo and submodules. A nice side-effect is that the repo checkout on all builds after the first one takes ~1 minute instead of ~5 minutes. Previous issues: - https://github.com/status-im/status-desktop/pull/7968 - https://github.com/status-im/status-desktop/pull/8046 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-03 09:36:47 +00:00
clean-git:
ci: extract git cleanup to separate script It needs to be separate script, because once the submodules are broken and the `variables.mk` file is not available from `nimbus-build-system` then we cannot even call `make clean-git` successfully because it will be caught by the `if` clause that checks for `variables.mk`. Possible fix for issues with submodules not being updated in some windows release builds. Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-22 12:40:45 +00:00
./scripts/clean-git.sh
ci: use git clean instead of cleanWs() function This is a continuation of attempts to fix provlems with Windows CI hosts getting into a broken state due to `.git` directory becoming a file for random submodules for unknown reason. Instead of relying on Jenkins functionality of `cleanWs()` function provided by the [Workspace Cleanup Plugin](https://plugins.jenkins.io/ws-cleanup) we use Git which should be more reliable, and possibly also speed up the initial checkout of the repo and submodules. A nice side-effect is that the repo checkout on all builds after the first one takes ~1 minute instead of ~5 minutes. Previous issues: - https://github.com/status-im/status-desktop/pull/7968 - https://github.com/status-im/status-desktop/pull/8046 Signed-off-by: Jakub Sokołowski <jakub@status.im>
2022-11-03 09:36:47 +00:00
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
chore(debug): use WAKUV2_PORT environment variable to change Waku V2 port The environment variable overrides libp2p protocol TCP port and discovery v5 UDP with the same value
2022-09-28 09:03:30 +00:00
# WAKUV2_PORT ?= 30307
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
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/nim_status_client"
chore(Makefile): ensure LD_LIBRARY_PATH is not overriden
2023-06-06 21:44:12 +00:00
LD_LIBRARY_PATH="$(QT5_LIBDIR)":"$(STATUSGO_LIBDIR)":"$(STATUSKEYCARDGO_LIBDIR):$(LD_LIBRARY_PATH)" \
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
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/StatusDev.app/Contents/MacOS/nim_status_client"
build: modify run logic for macOS dev builds so notifications work
2021-04-30 18:58:55 +00:00
./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)
fix(Makefile): Fixed ANSI coloring
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/nim_status_client.exe"
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
PATH="$(DOTHERSIDE_LIBDIR)":"$(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
chore(makefile): improve dotherside build (#11756)
2023-08-02 11:25:05 +00:00
tests-nim-linux: | dotherside
chore(Makefile): ensure LD_LIBRARY_PATH is not overriden
2023-06-06 21:44:12 +00:00
LD_LIBRARY_PATH="$(QT5_LIBDIR):$(LD_LIBRARY_PATH)" \
feat: introduce nim tests
2022-12-19 18:55:40 +00:00
$(ENV_SCRIPT) nim c $(NIM_PARAMS) $(NIM_EXTRA_PARAMS) -r test/nim/message_model_test.nim
Adding nimbus-build-system
2020-05-14 14:58:08 +00:00
endif # "variables.mk" was not included