2020-05-14 14:58:08 +00:00
# Copyright (c) 2019-2020 Status Research & Development GmbH. Licensed under
# either of:
# - Apache License, version 2.0
# - MIT license
# at your option. This file may not be copied, modified, or distributed except
# according to those terms.
2020-05-06 21:26:32 +00:00
2020-05-14 14:58:08 +00:00
SHELL := bash # the shell used internally by Make
2020-05-06 21:43:20 +00:00
2020-05-14 14:58:08 +00:00
# used inside the included makefiles
BUILD_SYSTEM_DIR := vendor/nimbus-build-system
# we don't want an error here, so we can handle things later, in the ".DEFAULT" target
- i n c l u d e $( BUILD_SYSTEM_DIR ) / m a k e f i l e s / v a r i a b l e s . m k
.PHONY : \
all \
2024-08-13 15:57:59 +00:00
nix-shell \
2020-06-04 20:56:44 +00:00
bottles \
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 \
2020-05-14 14:58:08 +00:00
clean \
2022-07-14 16:58:20 +00:00
compile-translations \
2020-05-14 14:58:08 +00:00
deps \
2020-12-10 16:56:32 +00:00
fleets-remove \
fleets-update \
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 \
2020-06-04 20:56:44 +00:00
pkg \
pkg-linux \
pkg-macos \
2020-07-08 16:48:13 +00:00
pkg-windows \
2020-05-25 02:18:37 +00:00
run \
2020-08-06 21:14:06 +00:00
run-linux \
run-macos \
2020-07-08 16:48:13 +00:00
run-windows \
2022-12-19 18:55:40 +00:00
tests-nim-linux \
2020-06-18 16:44:22 +00:00
status-go \
2022-07-21 11:29:18 +00:00
status-keycard-go \
2022-11-21 16:23:32 +00:00
statusq-sanity-checker \
run-statusq-sanity-checker \
2023-09-05 13:46:29 +00:00
statusq-tests \
run-statusq-tests \
2023-10-16 08:48:56 +00:00
storybook-build \
run-storybook \
run-storybook-tests \
2020-05-14 14:58:08 +00:00
update
i f e q ( $( 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?
e l s e # "variables.mk" was included. Business as usual until the end of this file.
2020-05-25 02:18:37 +00:00
all : nim_status_client
2024-08-13 15:57:59 +00:00
nix-shell : export NIX_USER_CONF_FILES := $( PWD ) /nix /nix .conf
2024-10-09 09:16:33 +00:00
nix-shell :
2024-08-13 15:57:59 +00:00
nix-shell
2020-05-25 02:18:37 +00:00
# must be included after the default target
- i n c l u d e $( BUILD_SYSTEM_DIR ) / m a k e f i l e s / t a r g e t s . m k
2020-05-14 14:58:08 +00:00
i f e q ( $( OS ) , W i n d o w s _ N T ) # is Windows_NT on XP, 2000, 7, Vista, 10...
2020-05-25 02:18:37 +00:00
detected_OS := Windows
2020-05-14 14:58:08 +00:00
e l s e
2020-05-25 02:18:37 +00:00
detected_OS := $( strip $( shell uname) )
2020-05-14 14:58:08 +00:00
e n d i f
2020-07-08 16:48:13 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
2024-09-03 15:56:52 +00:00
CFLAGS := -mmacosx-version-min= 12.0
2020-06-04 20:56:44 +00:00
export CFLAGS
2024-09-03 15:56:52 +00:00
CGO_CFLAGS := -mmacosx-version-min= 12.0
2020-07-08 16:48:13 +00:00
export CGO_CFLAGS
2020-08-06 21:14:06 +00:00
LIBSTATUS_EXT := dylib
2023-11-20 16:04:11 +00:00
# keep in sync with BOTTLE_MACOS_VERSION
2024-09-03 15:56:52 +00:00
MACOSX_DEPLOYMENT_TARGET := 12.0
2020-07-08 16:48:13 +00:00
export MACOSX_DEPLOYMENT_TARGET
PKG_TARGET := pkg-macos
2020-08-06 21:14:06 +00:00
RUN_TARGET := run-macos
2023-03-10 10:36:03 +00:00
QMAKE_PATH := $( shell which qmake) ;
QT_ARCH := $( shell lipo -archs $( QMAKE_PATH) )
2020-07-08 16:48:13 +00:00
e l s e i f e q ( $( detected_OS ) , W i n d o w s )
2020-08-06 21:14:06 +00:00
LIBSTATUS_EXT := dll
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
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
2020-06-04 20:56:44 +00:00
e l s e
2020-08-06 21:14:06 +00:00
LIBSTATUS_EXT := so
2020-06-04 20:56:44 +00:00
PKG_TARGET := pkg-linux
2020-08-06 21:14:06 +00:00
RUN_TARGET := run-linux
2020-06-04 20:56:44 +00:00
e n d i f
2022-11-08 09:11:53 +00:00
check-qt-dir :
2022-12-26 09:22:25 +00:00
i f e q ( $( 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)
2022-11-08 09:11:53 +00:00
e n d i f
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 :
i f n e q ( $( detected_OS ) , L i n u x )
$( error The pkg-linux target must be run on Linux)
e n d i f
check-pkg-target-macos :
i f n e q ( $( detected_OS ) , D a r w i n )
$( error The pkg-macos target must be run on macOS)
e n d i f
check-pkg-target-windows :
i f n e q ( $( detected_OS ) , W i n d o w s )
$( error The pkg-windows target must be run on Windows)
e n d i f
2021-04-15 21:14:30 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
2021-09-16 22:32:00 +00:00
BOTTLES_DIR := $( shell pwd ) /bottles
2022-12-09 10:26:02 +00:00
BOTTLES := $( addprefix $( BOTTLES_DIR) /,openssl@1.1 pcre)
2023-03-10 10:36:03 +00:00
i f e q ( $( QT_ARCH ) , a r m 6 4 )
2023-11-20 16:04:11 +00:00
# keep in sync with MACOSX_DEPLOYMENT_TARGET
2024-09-03 15:56:52 +00:00
BOTTLE_MACOS_VERSION := 'arm64_monterey'
2023-03-10 10:36:03 +00:00
e l s e
2024-09-03 15:56:52 +00:00
BOTTLE_MACOS_VERSION := 'monterey'
2023-03-10 10:36:03 +00:00
e n d i f
2021-09-16 22:32:00 +00:00
$(BOTTLES) : | $( BOTTLES_DIR )
2023-11-20 16:04:11 +00:00
echo -e " \033[92mFetching:\033[39m $( notdir $@ ) bottle arch $( QT_ARCH) $( BOTTLE_MACOS_VERSION) "
./scripts/fetch-brew-bottle.sh $( notdir $@ ) $( BOTTLE_MACOS_VERSION) $( HANDLE_OUTPUT)
2021-09-16 22:32:00 +00:00
$(BOTTLES_DIR) :
2023-01-23 13:24:56 +00:00
echo -e "\033[92mUpdating:\033[39m macOS Homebrew"
2023-10-31 11:13:47 +00:00
if [ [ $$ ( stat -f %u /usr/local/var/homebrew) -ne " $$ {UID} " ] ] && [ [ $$ ( stat -f %u /opt/homebrew/bin/brew) -ne " $$ {UID} " ] ] ; then \
2021-09-16 22:32:00 +00:00
echo "Missing permissions to update Homebrew formulae!" >& 2; \
else \
brew update >/dev/null; \
mkdir -p $( BOTTLES_DIR) ; \
fi
bottles : $( BOTTLES )
2021-04-15 21:14:30 +00:00
e n d i f
2020-06-04 20:56:44 +00:00
2024-10-08 14:06:20 +00:00
deps : | check -qt -dir deps -common status -go -deps bottles
2020-05-14 14:58:08 +00:00
2022-11-14 12:00:39 +00:00
update : | check -qt -dir update -common
2024-07-18 15:36:11 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
# Install or update package.json files
yarn install --check-files
e n d i f
2020-05-25 02:18:37 +00:00
2022-08-11 09:14:22 +00:00
QML_DEBUG ?= false
QML_DEBUG_PORT ?= 49152
i f n e q ( $( QML_DEBUG ) , f a l s e )
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_BUILD_TYPE = Debug
DOTHERSIDE_CMAKE_CONFIG_PARAMS := -DQML_DEBUG_PORT= $( QML_DEBUG_PORT)
2022-08-11 09:14:22 +00:00
e l s e
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_BUILD_TYPE = Release
2022-08-11 09:14:22 +00:00
e n d i f
2023-01-04 16:05:07 +00:00
MONITORING ?= false
i f n e q ( $( MONITORING ) , f a l s e )
2023-08-02 11:25:05 +00:00
DOTHERSIDE_CMAKE_CONFIG_PARAMS += -DMONITORING:BOOL= ON -DMONITORING_QML_ENTRY_POINT:STRING= "/../monitoring/Main.qml"
2023-01-04 16:05:07 +00:00
e n d i f
2020-05-25 02:18:37 +00:00
# Qt5 dirs (we can't indent with tabs here)
2020-07-08 16:48:13 +00:00
i f n e q ( $( detected_OS ) , W i n d o w s )
2023-06-02 09:28:18 +00:00
export QT5_LIBDIR := $( shell qmake -query QT_INSTALL_LIBS 2>/dev/null)
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
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) "
2020-05-25 02:18:37 +00:00
endif
2023-08-02 11:25:05 +00:00
DOTHERSIDE_LIBFILE := vendor/DOtherSide/build/lib/libDOtherSideStatic.a
2020-07-08 16:48:13 +00:00
# order matters here, due to "-Wl,-as-needed"
2023-11-16 15:15:37 +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 Qt5WebView Qt5WebChannel) "
2020-07-08 16:48:13 +00:00
e l s e
NIM_EXTRA_PARAMS := --passL:"-lsetupapi -lhid"
2020-05-25 02:18:37 +00:00
e n d i f
2021-09-23 13:38:38 +00:00
2023-08-02 11:25:05 +00:00
i f e q ( $( detected_OS ) , W i n d o w s )
COMMON_CMAKE_CONFIG_PARAMS := -T"v141" -A x64
e n d i f
2021-09-23 13:38:38 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
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"
2023-08-02 11:25:05 +00:00
COMMON_CMAKE_CONFIG_PARAMS += -DCMAKE_OSX_ARCHITECTURES= x86_64
2023-03-10 10:36:03 +00:00
QRCODEGEN_MAKE_PARAMS += CFLAGS = "-target x86_64-apple-macos10.12"
2021-09-23 13:38:38 +00:00
NIM_PARAMS += --cpu:amd64 --os:MacOSX --passL:"-arch x86_64" --passC:"-arch x86_64"
endif
2023-03-10 10:36:03 +00:00
endif
2021-09-23 13:38:38 +00:00
e n d i f
2024-02-23 09:19:57 +00:00
INCLUDE_DEBUG_SYMBOLS ?= false
i f e q ( $( INCLUDE_DEBUG_SYMBOLS ) , t r u e )
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
# 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
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
e l s e
# 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
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
e n d i f
NIM_PARAMS += --outdir:./bin
2020-05-14 14:58:08 +00:00
2021-06-17 18:41:11 +00:00
# App version
VERSIONFILE = VERSION
DESKTOP_VERSION = ` cat $( VERSIONFILE) `
2024-08-12 19:02:59 +00:00
STATUSGO_VERSION = ` ( cd vendor/status-go; git describe --tags --abbrev= 0) `
2021-06-17 18:41:11 +00:00
NIM_PARAMS += -d:DESKTOP_VERSION= " $( DESKTOP_VERSION) "
2023-07-26 14:34:21 +00:00
NIM_PARAMS += -d:STATUSGO_VERSION= " $( STATUSGO_VERSION) "
2021-06-17 18:41:11 +00:00
2022-03-24 11:51:24 +00:00
GIT_COMMIT = ` git log --pretty= format:'%h' -n 1`
NIM_PARAMS += -d:GIT_COMMIT= " $( GIT_COMMIT) "
2022-06-30 15:11:40 +00:00
OUTPUT_CSV ?= false
i f e q ( $( OUTPUT_CSV ) , t r u e )
NIM_PARAMS += -d:output_csv
$( shell touch .update.timestamp)
e n d i f
2023-04-14 08:18:56 +00:00
##
## StatusQ
##
2023-08-02 11:25:05 +00:00
STATUSQ_SOURCE_PATH := ui/StatusQ
2023-04-14 08:18:56 +00:00
STATUSQ_BUILD_PATH := ui/StatusQ/build
2024-10-11 15:14:21 +00:00
export STATUSQ_INSTALL_PATH := $( shell pwd ) /bin
2023-04-14 08:18:56 +00:00
STATUSQ_CMAKE_CACHE := $( STATUSQ_BUILD_PATH) /CMakeCache.txt
2024-08-21 09:50:37 +00:00
$(STATUSQ_CMAKE_CACHE) : | check -qt -dir
2023-04-14 08:18:56 +00:00
echo -e "\033[92mConfiguring:\033[39m StatusQ"
2023-08-02 11:25:05 +00:00
cmake \
-DCMAKE_INSTALL_PREFIX= $( STATUSQ_INSTALL_PATH) \
-DCMAKE_BUILD_TYPE= $( COMMON_CMAKE_BUILD_TYPE) \
2023-04-14 08:18:56 +00:00
-DSTATUSQ_BUILD_SANDBOX= OFF \
-DSTATUSQ_BUILD_SANITY_CHECKER= OFF \
-DSTATUSQ_BUILD_TESTS= OFF \
2023-08-02 11:25:05 +00:00
$( COMMON_CMAKE_CONFIG_PARAMS) \
2023-04-14 08:18:56 +00:00
-B $( STATUSQ_BUILD_PATH) \
2023-08-02 11:25:05 +00:00
-S $( STATUSQ_SOURCE_PATH) \
2023-04-25 15:01:19 +00:00
-Wno-dev \
2023-04-14 08:18:56 +00:00
$( HANDLE_OUTPUT)
2023-09-22 10:38:44 +00:00
statusq-configure : | $( STATUSQ_CMAKE_CACHE )
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 \
2023-08-02 11:25:05 +00:00
--config $( COMMON_CMAKE_BUILD_TYPE) \
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 \
2023-08-02 11:25:05 +00:00
-B $( STATUSQ_BUILD_PATH) \
-S $( STATUSQ_SOURCE_PATH) \
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
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 \
2023-11-18 16:06:04 +00:00
-DSTATUSQ_SHADOW_BUILD= OFF \
2023-09-05 13:46:29 +00:00
-B $( STATUSQ_BUILD_PATH) \
-S $( STATUSQ_SOURCE_PATH) \
$( HANDLE_OUTPUT)
echo -e "\033[92mBuilding:\033[39m StatusQ Unit Tests"
cmake \
--build $( STATUSQ_BUILD_PATH) \
$( HANDLE_OUTPUT)
2024-10-04 15:12:07 +00:00
run-statusq-tests : export QTWEBENGINE_CHROMIUM_FLAGS := "${QTWEBENGINE_CHROMIUM_FLAGS } --disable -seccomp -filter -sandbox "
2023-09-05 13:46:29 +00:00
run-statusq-tests : statusq -tests
echo -e "\033[92mRunning:\033[39m StatusQ Unit Tests"
2023-11-23 11:38:09 +00:00
ctest -V --test-dir $( STATUSQ_BUILD_PATH) ${ ARGS }
2023-10-16 08:48:56 +00:00
##
## Storybook
##
STORYBOOK_SOURCE_PATH := storybook
STORYBOOK_BUILD_PATH := $( STORYBOOK_SOURCE_PATH) /build
STORYBOOK_CMAKE_CACHE := $( STORYBOOK_BUILD_PATH) /CMakeCache.txt
2024-08-21 09:50:37 +00:00
$(STORYBOOK_CMAKE_CACHE) : | check -qt -dir
2023-10-16 08:48:56 +00:00
echo -e "\033[92mConfiguring:\033[39m Storybook"
cmake \
-DCMAKE_INSTALL_PREFIX= $( STORYBOOK_INSTALL_PATH) \
-DCMAKE_BUILD_TYPE= $( COMMON_CMAKE_BUILD_TYPE) \
-DSTATUSQ_SHADOW_BUILD= OFF \
$( COMMON_CMAKE_CONFIG_PARAMS) \
-B $( STORYBOOK_BUILD_PATH) \
-S $( STORYBOOK_SOURCE_PATH) \
-Wno-dev \
$( HANDLE_OUTPUT)
storybook-configure : | $( STORYBOOK_CMAKE_CACHE )
storybook-build : | storybook -configure
echo -e "\033[92mBuilding:\033[39m Storybook"
cmake --build $( STORYBOOK_BUILD_PATH) \
--config $( COMMON_CMAKE_BUILD_TYPE) \
$( HANDLE_OUTPUT)
run-storybook : storybook -build
echo -e "\033[92mRunning:\033[39m Storybook"
$( STORYBOOK_BUILD_PATH) /bin/Storybook
run-storybook-tests : storybook -build
echo -e "\033[92mRunning:\033[39m Storybook Tests"
2023-10-18 07:51:13 +00:00
ctest -V --test-dir $( STORYBOOK_BUILD_PATH) -E PagesValidator
# repeat because of https://bugreports.qt.io/browse/QTBUG-92236 (Qt < 5.15.4)
run-storybook-pages-validator : storybook -build
echo -e "\033[92mRunning:\033[39m Storybook Pages Validator"
ctest -V --test-dir $( STORYBOOK_BUILD_PATH) -R PagesValidator --repeat until -pass:3
2023-10-16 08:48:56 +00:00
storybook-clean :
echo -e "\033[92mCleaning:\033[39m Storybook"
rm -rf $( STORYBOOK_BUILD_PATH)
2023-04-14 08:18:56 +00:00
##
## DOtherSide
##
2023-08-02 11:25:05 +00:00
i f n e q ( $( detected_OS ) , W i n d o w s )
DOTHERSIDE_CMAKE_CONFIG_PARAMS += -DENABLE_DYNAMIC_LIBS= OFF -DENABLE_STATIC_LIBS= ON
2023-09-22 10:38:44 +00:00
# NIM_PARAMS +=
2023-08-02 11:25:05 +00:00
e l s e
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)
e n d i f
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)
2023-04-25 15:01:19 +00:00
2023-09-22 10:38:44 +00:00
dotherside-configure : | $( DOTHERSIDE_CMAKE_CACHE )
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)
2023-04-25 15:01:19 +00:00
dotherside-clean :
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
##
2020-05-14 14:58:08 +00:00
2022-02-03 14:23:51 +00:00
STATUSGO := vendor/status-go/build/bin/libstatus.$( LIBSTATUS_EXT)
2020-08-06 21:14:06 +00:00
STATUSGO_LIBDIR := $( shell pwd ) /$( shell dirname " $( STATUSGO) " )
export STATUSGO_LIBDIR
2020-05-14 20:19:01 +00:00
2024-10-08 14:06:20 +00:00
$(STATUSGO) : | deps status -go -deps
2020-05-14 20:19:01 +00:00
echo -e $( BUILD_MSG) "status-go"
2024-04-11 22:08:21 +00:00
# FIXME: Nix shell usage breaks builds due to Glibc mismatch.
$( MAKE) -C vendor/status-go statusgo-shared-library SHELL = /bin/sh \
2024-11-25 18:59:53 +00:00
SENTRY_CONTEXT_NAME = "status-desktop" \
SENTRY_CONTEXT_VERSION = " $( DESKTOP_VERSION) " \
2024-04-11 22:08:21 +00:00
$( STATUSGO_MAKE_PARAMS) $( HANDLE_OUTPUT)
2020-05-14 14:58:08 +00:00
2023-04-25 15:01:19 +00:00
status-go : $( STATUSGO )
2024-10-08 14:06:20 +00:00
status-go-deps :
go install go.uber.org/mock/mockgen@v0.4.0
go install github.com/kevinburke/go-bindata/v4/...@v4.0.2
2024-10-09 09:16:33 +00:00
go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.34.1
2024-10-08 14:06:20 +00:00
2023-04-25 15:01:19 +00:00
status-go-clean :
echo -e "\033[92mCleaning:\033[39m status-go"
rm -f $( STATUSGO)
2024-01-25 14:53:22 +00:00
export STATUSKEYCARDGO := vendor/status-keycard-go/build/libkeycard/libkeycard.$( LIBSTATUS_EXT)
2023-10-11 16:47:05 +00:00
export STATUSKEYCARDGO_LIBDIR := " $( shell pwd ) / $( shell dirname " $( STATUSKEYCARDGO) " ) "
2023-09-22 10:38:44 +00:00
2022-07-21 11:29:18 +00:00
status-keycard-go : $( STATUSKEYCARDGO )
$(STATUSKEYCARDGO) : | deps
echo -e $( BUILD_MSG) "status-keycard-go"
2023-10-11 16:47:05 +00:00
+ $( MAKE) -C vendor/status-keycard-go \
$( if $( filter 1 true,$( USE_MOCKED_KEYCARD_LIB) ) , build-mocked-lib, build-lib) \
$( STATUSKEYCARDGO_MAKE_PARAMS) $( HANDLE_OUTPUT)
2021-09-28 08:06:19 +00:00
2020-06-23 17:17:58 +00:00
QRCODEGEN := vendor/QR-Code-generator/c/libqrcodegen.a
$(QRCODEGEN) : | deps
echo -e $( BUILD_MSG) "QR-Code-generator"
+ cd vendor/QR-Code-generator/c && \
2023-04-25 15:01:19 +00:00
$( MAKE) $( QRCODEGEN_MAKE_PARAMS) $( HANDLE_OUTPUT)
2020-06-23 17:17:58 +00:00
2024-01-25 14:53:22 +00:00
export FLEETS_FILE := ./fleets.json
2022-12-09 07:33:02 +00:00
$(FLEETS_FILE) :
echo -e $( BUILD_MSG) " Getting latest $( FLEETS_FILE) "
curl -s https://fleets.status.im/ > $( FLEETS_FILE)
2020-11-03 19:42:55 +00:00
2020-12-10 16:56:32 +00:00
fleets-remove :
2022-12-09 07:33:02 +00:00
rm -f $( FLEETS_FILE)
2020-11-06 15:50:58 +00:00
2022-12-09 07:33:02 +00:00
fleets-update : fleets -remove $( FLEETS_FILE )
2020-10-30 01:53:34 +00:00
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
i f e q ( $( REBUILD_UI ) , t r u e )
$( shell touch ui/main.qml)
e n d i f
2021-09-16 21:17:10 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
UI_SOURCES := $( shell find -E ui -type f -iregex '.*(qmldir|qml|qrc)$$' -not -iname 'resources.qrc' )
e l s e
UI_SOURCES := $( shell find ui -type f -regextype egrep -iregex '.*(qmldir|qml|qrc)$$' -not -iname 'resources.qrc' )
e n d i f
2021-09-21 16:28:25 +00:00
UI_RESOURCES := resources.rcc
2022-11-14 12:00:39 +00:00
$(UI_RESOURCES) : $( UI_SOURCES ) | check -qt -dir
2020-07-08 16:48:13 +00:00
echo -e $( BUILD_MSG) "resources.rcc"
2020-07-07 18:13:41 +00:00
rm -f ./resources.rcc
rm -f ./ui/resources.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
2020-06-30 21:35:24 +00:00
2021-09-16 21:17:10 +00:00
rcc : $( UI_RESOURCES )
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 /')
2022-11-14 12:00:39 +00:00
$(QM_BINARIES) : $( TS_SOURCES ) | check -qt -dir
2022-07-14 16:58:20 +00:00
mkdir -p bin/i18n
2023-04-14 08:18:56 +00:00
lrelease -removeidentical $( TS_FILE) -qm $@ $( HANDLE_OUTPUT)
2022-07-14 16:58:20 +00:00
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 )
2022-07-14 16:58:20 +00:00
2022-08-15 13:46:19 +00:00
# used to override the default number of kdf iterations for sqlcipher
KDF_ITERATIONS ?= 0
i f e q ( $( shell test $ ( KDF_ITERATIONS ) -gt 0; echo $ $ ?) , 0 )
NIM_PARAMS += -d:KDF_ITERATIONS:" $( KDF_ITERATIONS) "
e n d i f
2023-12-04 10:11:03 +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 -d:chronicles_log_level= trace
2021-06-29 18:42:18 +00:00
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
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
i f e q ( $( REBUILD_NIM ) , t r u e )
$( shell touch .update.timestamp)
e n d i f
.update.timestamp :
touch .update.timestamp
NIM_SOURCES := .update.timestamp $( shell find src -type f)
2024-05-17 06:49:51 +00:00
STATUS_RC_FILE := status.rc
# Building the resource files for windows to set the icon
compile_windows_resources :
windres $( STATUS_RC_FILE) -o status.o
2021-09-16 21:17:10 +00:00
i f e q ( $( detected_OS ) , W i n d o w s )
NIM_STATUS_CLIENT := bin/nim_status_client.exe
e l s e
NIM_STATUS_CLIENT := bin/nim_status_client
e n d i f
$(NIM_STATUS_CLIENT) : NIM_PARAMS += $( RESOURCES_LAYOUT )
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
2023-06-05 11:38:37 +00:00
echo -e $( BUILD_MSG) " $@ "
$( ENV_SCRIPT) nim c $( NIM_PARAMS) \
--passL:" -L $( STATUSGO_LIBDIR) " \
--passL:"-lstatus" \
2024-10-11 15:14:21 +00:00
--passL:" -L $( STATUSQ_INSTALL_PATH) /StatusQ " \
--passL:"-lStatusQ" \
2023-06-05 11:38:37 +00:00
--passL:" -L $( STATUSKEYCARDGO_LIBDIR) " \
--passL:"-lkeycard" \
--passL:" $( QRCODEGEN) " \
--passL:"-lm" \
$( NIM_EXTRA_PARAMS) src/nim_status_client.nim
2022-09-14 15:44:15 +00:00
i f e q ( $( detected_OS ) , D a r w i n )
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
2022-09-14 15:44:15 +00:00
e n d i f
2020-05-14 20:19:01 +00:00
2021-12-15 09:13:06 +00:00
nim_status_client : force -rebuild -status -go $( NIM_STATUS_CLIENT )
2021-09-16 21:17:10 +00:00
2024-06-25 13:53:01 +00:00
i f d e f I N _ N I X _ S H E L L
APPIMAGE_TOOL := appimagetool
e l s e
APPIMAGE_TOOL := tmp/linux/tools/appimagetool
e n d i f
2020-06-04 20:56:44 +00:00
2024-06-25 13:53:01 +00:00
_APPIMAGE_TOOL := appimagetool-x86_64.AppImage
2020-06-04 20:56:44 +00:00
$(APPIMAGE_TOOL) :
2024-06-25 13:53:01 +00:00
i f n d e f I N _ N I X _ S H E L L
2023-01-23 13:24:56 +00:00
echo -e "\033[92mFetching:\033[39m appimagetool"
2020-06-04 20:56:44 +00:00
rm -rf tmp/linux
mkdir -p tmp/linux/tools
2021-08-04 15:41:31 +00:00
wget -nv https://github.com/AppImage/AppImageKit/releases/download/continuous/$( _APPIMAGE_TOOL)
2024-01-19 15:23:26 +00:00
mv $( _APPIMAGE_TOOL) $( APPIMAGE_TOOL)
2020-06-04 20:56:44 +00:00
chmod +x $( APPIMAGE_TOOL)
2024-06-25 13:53:01 +00:00
e n d i f
2020-05-19 15:32:48 +00:00
2021-04-21 20:13:21 +00:00
STATUS_CLIENT_APPIMAGE ?= pkg/Status.AppImage
2021-06-04 19:44:39 +00:00
STATUS_CLIENT_TARBALL ?= pkg/Status.tar.gz
2021-08-04 15:41:31 +00:00
STATUS_CLIENT_TARBALL_FULL ?= $( shell realpath $( STATUS_CLIENT_TARBALL) )
2020-05-14 20:19:01 +00:00
2022-01-20 23:28:31 +00:00
i f e q ( $( detected_OS ) , L i n u x )
2024-01-25 14:53:22 +00:00
export FCITX5_QT := vendor/fcitx5-qt/build/qt5/platforminputcontext/libfcitx5platforminputcontextplugin.so
2022-01-20 23:28:31 +00:00
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)
e n d i f
2022-11-14 12:00:39 +00:00
$(FCITX5_QT) : | check -qt -dir deps
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)
2024-05-10 07:18:43 +00:00
PRODUCTION_PARAMETERS ?= -d:production
2022-03-25 15:48:26 +00:00
2024-01-25 14:53:22 +00:00
export APP_DIR := tmp/linux/dist
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_APPIMAGE) : override RESOURCES_LAYOUT := $( PRODUCTION_PARAMETERS )
2022-01-20 23:28:31 +00:00
$(STATUS_CLIENT_APPIMAGE) : nim_status_client $( APPIMAGE_TOOL ) nim -status .desktop $( FCITX 5_QT )
2020-06-04 20:56:44 +00:00
rm -rf pkg/*.AppImage
2024-01-25 14:53:22 +00:00
chmod -R u+w tmp || true
scripts/init_app_dir.sh
2020-08-06 21:14:06 +00:00
2020-05-14 20:19:01 +00:00
echo -e $( BUILD_MSG) "AppImage"
2024-06-25 13:53:01 +00:00
2024-01-25 14:53:22 +00:00
linuxdeployqt $( APP_DIR) /nim-status.desktop \
-no-copy-copyright-files \
-qmldir= ui -qmlimport= $( QT5_QMLDIR) \
-bundle-non-qt-libs \
-exclude-libs= libgmodule-2.0.so.0,libgthread-2.0.so.0 \
-verbose= 1 \
-executable= $( APP_DIR) /usr/libexec/QtWebEngineProcess
2020-06-04 20:56:44 +00:00
2024-01-25 14:53:22 +00:00
scripts/fix_app_dir.sh
2022-01-20 23:28:31 +00:00
2024-01-25 14:53:22 +00:00
rm $( APP_DIR) /AppRun
cp AppRun $( APP_DIR) /.
2020-06-04 20:56:44 +00:00
mkdir -p pkg
2024-01-25 14:53:22 +00:00
$( APPIMAGE_TOOL) $( APP_DIR) $( STATUS_CLIENT_APPIMAGE)
# Fix rpath and interpreter for AppImage
2024-06-25 13:53:01 +00:00
i f d e f I N _ N I X _ S H E L L
patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 $( STATUS_CLIENT_APPIMAGE)
2024-01-25 14:53:22 +00:00
patchelf --remove-rpath $( STATUS_CLIENT_APPIMAGE)
2024-06-25 13:53:01 +00:00
e n d i f
2021-08-04 15:41:31 +00:00
# if LINUX_GPG_PRIVATE_KEY_FILE is not set then we don't generate a signature
i f d e f L I N U X _ G P G _ P R I V A T E _ K E Y _ F I L E
scripts/sign-linux-file.sh $( STATUS_CLIENT_APPIMAGE)
e n d i f
2020-06-04 20:56:44 +00:00
2021-06-04 19:44:39 +00:00
$(STATUS_CLIENT_TARBALL) : $( STATUS_CLIENT_APPIMAGE )
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}
i f d e f L I N U X _ G P G _ P R I V A T E _ K E Y _ F I L E
scripts/sign-linux-file.sh $( STATUS_CLIENT_TARBALL)
e n d i f
2021-06-04 19:44:39 +00:00
2020-06-04 20:56:44 +00:00
DMG_TOOL := node_modules/.bin/create-dmg
2020-05-15 13:00:49 +00:00
2020-06-04 20:56:44 +00:00
$(DMG_TOOL) :
2023-01-23 13:24:56 +00:00
echo -e "\033[92mInstalling:\033[39m create-dmg"
2023-10-31 11:13:47 +00:00
yarn install
2020-05-15 13:00:49 +00:00
2020-09-22 15:12:48 +00:00
MACOS_OUTER_BUNDLE := tmp/macos/dist/Status.app
MACOS_INNER_BUNDLE := $( MACOS_OUTER_BUNDLE) /Contents/Frameworks/QtWebEngineCore.framework/Versions/Current/Helpers/QtWebEngineProcess.app
2020-05-14 20:19:01 +00:00
2020-06-18 16:44:22 +00:00
STATUS_CLIENT_DMG ?= pkg/Status.dmg
2020-06-04 20:56:44 +00:00
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_DMG) : override RESOURCES_LAYOUT := $( PRODUCTION_PARAMETERS )
2023-08-08 10:08:21 +00:00
$(STATUS_CLIENT_DMG) : ENTITLEMENTS ?= resources /Entitlements .plist
2020-06-18 16:44:22 +00:00
$(STATUS_CLIENT_DMG) : nim_status_client $( DMG_TOOL )
2020-06-04 20:56:44 +00:00
rm -rf tmp/macos pkg/*.dmg
2020-09-22 15:12:48 +00:00
mkdir -p $( MACOS_OUTER_BUNDLE) /Contents/MacOS
mkdir -p $( MACOS_OUTER_BUNDLE) /Contents/Resources
cp Info.plist $( MACOS_OUTER_BUNDLE) /Contents/
cp bin/nim_status_client $( MACOS_OUTER_BUNDLE) /Contents/MacOS/
2021-01-19 16:10:36 +00:00
cp status.icns $( MACOS_OUTER_BUNDLE) /Contents/Resources/
2021-07-19 16:00:05 +00:00
cp status-macos.svg $( MACOS_OUTER_BUNDLE) /Contents/
2020-09-22 15:12:48 +00:00
cp -R resources.rcc $( MACOS_OUTER_BUNDLE) /Contents/
2022-12-09 07:33:02 +00:00
cp -R $( FLEETS_FILE) $( MACOS_OUTER_BUNDLE) /Contents/
2020-09-22 15:12:48 +00:00
mkdir -p $( MACOS_OUTER_BUNDLE) /Contents/i18n
2022-07-14 16:58:20 +00:00
cp bin/i18n/* $( MACOS_OUTER_BUNDLE) /Contents/i18n
2020-06-04 20:56:44 +00:00
2020-07-08 16:48:13 +00:00
echo -e $( BUILD_MSG) "app"
2020-06-04 20:56:44 +00:00
macdeployqt \
2020-09-22 15:12:48 +00:00
$( MACOS_OUTER_BUNDLE) \
-executable= $( MACOS_OUTER_BUNDLE) /Contents/MacOS/nim_status_client \
2020-06-04 20:56:44 +00:00
-qmldir= ui
2020-09-22 15:12:48 +00:00
macdeployqt \
$( MACOS_INNER_BUNDLE) \
-executable= $( MACOS_INNER_BUNDLE) /Contents/MacOS/QtWebEngineProcess
2020-06-04 20:56:44 +00:00
2020-09-22 15:12:48 +00:00
# if MACOS_CODESIGN_IDENT is not set then the outer and inner .app
# bundles are not signed
2020-06-18 16:44:22 +00:00
i f d e f M A C O S _ C O D E S I G N _ I D E N T
2023-08-08 10:08:21 +00:00
scripts/sign-macos-pkg.sh $( MACOS_OUTER_BUNDLE) $( MACOS_CODESIGN_IDENT) \
--entitlements $( ENTITLEMENTS)
2020-06-18 16:44:22 +00:00
e n d i f
2020-07-08 16:48:13 +00:00
echo -e $( BUILD_MSG) "dmg"
2020-06-04 20:56:44 +00:00
mkdir -p pkg
# See: https://github.com/sindresorhus/create-dmg#dmg-icon
# GraphicsMagick must be installed for create-dmg to make the custom
# DMG icon based on app icon, but should otherwise work without it
npx create-dmg \
--identity= "NOBODY" \
2020-09-22 15:12:48 +00:00
$( MACOS_OUTER_BUNDLE) \
2020-06-04 20:56:44 +00:00
pkg || true
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)
i f d e f M A C O S _ C O D E S I G N _ I D E N T
scripts/sign-macos-pkg.sh $( STATUS_CLIENT_DMG) $( MACOS_CODESIGN_IDENT)
e n d i f
2020-06-04 20:56:44 +00:00
2023-08-08 12:06:06 +00:00
notarize-macos : export CHECK_TIMEOUT ?= 10m
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) :
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 && \
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
2021-07-15 11:12:18 +00:00
STATUS_CLIENT_EXE ?= pkg/Status.exe
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
2022-03-25 15:48:26 +00:00
$(STATUS_CLIENT_EXE) : override RESOURCES_LAYOUT := $( PRODUCTION_PARAMETERS )
2021-07-15 11:12:18 +00:00
$(STATUS_CLIENT_EXE) : OUTPUT := tmp /windows /dist /Status
$(STATUS_CLIENT_EXE) : INSTALLER_OUTPUT := pkg
2024-05-17 06:49:51 +00:00
$(STATUS_CLIENT_EXE) : compile_windows_resources nim_status_client nim_windows_launcher $( NIM_WINDOWS_PREBUILT_DLLS )
2021-07-15 11:12:18 +00:00
rm -rf pkg/*.exe tmp/windows/dist
2024-10-11 15:14:21 +00:00
mkdir -p $( OUTPUT) /bin $( OUTPUT) /resources $( OUTPUT) /vendor $( OUTPUT) /resources/i18n
2021-04-19 14:45:46 +00:00
cat windows-install.txt | unix2dos > $( OUTPUT) /INSTALL.txt
2024-05-07 21:11:20 +00:00
cp status.ico status.png resources.rcc $( FLEETS_FILE) $( OUTPUT) /resources/
2022-07-14 16:58:20 +00:00
cp bin/i18n/* $( OUTPUT) /resources/i18n
2021-09-03 03:16:27 +00:00
cp cacert.pem $( OUTPUT) /bin/cacert.pem
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
2024-10-11 15:14:21 +00:00
cp $( DOTHERSIDE_LIBFILE) $( STATUSGO) $( STATUSKEYCARDGO) $( STATUSQ_INSTALL_PATH) /StatusQ/* tmp/windows/tools/*.dll $( OUTPUT) /bin/
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"
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/
2021-07-15 11:12:18 +00:00
cp status.iss $( OUTPUT) /status.iss
2021-04-19 14:45:46 +00:00
# if WINDOWS_CODESIGN_PFX_PATH is not set then DLLs, EXEs are not signed
2020-07-21 16:28:42 +00:00
i f d e f W I N D O W S _ C O D E S I G N _ P F X _ P A T H
2021-04-19 14:45:46 +00:00
scripts/sign-windows-bin.sh ./tmp/windows/dist/Status
2020-07-21 16:28:42 +00:00
e n d i f
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
i f d e f W I N D O W S _ C O D E S I G N _ P F X _ P A T H
scripts/sign-windows-bin.sh $( INSTALLER_OUTPUT)
e n d i f
2021-09-15 14:08:13 +00:00
$(STATUS_CLIENT_7Z) : OUTPUT := tmp /windows /dist /Status
$(STATUS_CLIENT_7Z) : $( STATUS_CLIENT_EXE )
2021-09-15 07:44:36 +00:00
echo -e $( BUILD_MSG) "7z"
2021-09-15 08:50:19 +00:00
7z a $( STATUS_CLIENT_7Z) ./$( OUTPUT)
2020-07-08 16:48:13 +00:00
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)
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 )
2020-06-04 20:56:44 +00:00
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 )
2020-05-14 14:58:08 +00:00
2021-07-15 11:12:18 +00:00
pkg-windows : check -pkg -target -windows $( STATUS_CLIENT_EXE )
2020-07-08 16:48:13 +00:00
2021-09-15 14:08:13 +00:00
zip-windows : check -pkg -target -windows $( STATUS_CLIENT_ 7Z )
2023-10-16 08:48:56 +00:00
clean : | clean -common statusq -clean status -go -clean dotherside -clean storybook -clean
2023-04-25 15:01:19 +00:00
rm -rf bin/* node_modules bottles/* pkg/* tmp/* $( STATUSKEYCARDGO)
2023-03-10 10:36:03 +00:00
+ $( MAKE) -C vendor/QR-Code-generator/c/ --no-print-directory clean
2020-06-04 20:56:44 +00:00
2022-11-03 09:36:47 +00:00
clean-git :
2022-11-22 12:40:45 +00:00
./scripts/clean-git.sh
2022-11-03 09:36:47 +00:00
2021-12-15 09:13:06 +00:00
force-rebuild-status-go :
bash ./scripts/force-rebuild-status-go.sh $( STATUSGO)
2021-09-21 16:28:25 +00:00
run : $( RUN_TARGET )
2020-07-08 16:48:13 +00:00
2021-01-19 16:10:36 +00:00
ICON_TOOL := node_modules/.bin/fileicon
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
2022-09-28 09:03:30 +00:00
# WAKUV2_PORT ?= 30307
2020-07-03 19:22:15 +00:00
2021-09-21 16:28:25 +00:00
run-linux : nim_status_client
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/nim_status_client"
2024-10-11 15:14:21 +00:00
LD_LIBRARY_PATH = " $( QT5_LIBDIR) " :" $( STATUSGO_LIBDIR) " :" $( STATUSKEYCARDGO_LIBDIR) " :" $( STATUSQ_INSTALL_PATH) /StatusQ " :" $( LD_LIBRARY_PATH) " \
2023-10-19 18:27:27 +00:00
./bin/nim_status_client $( ARGS)
2020-08-06 21:14:06 +00:00
2024-07-12 13:51:06 +00:00
run-linux-gdb : nim_status_client
echo -e "\033[92mRunning:\033[39m bin/nim_status_client"
2024-10-11 15:14:21 +00:00
LD_LIBRARY_PATH = " $( QT5_LIBDIR) " :" $( STATUSGO_LIBDIR) " :" $( STATUSKEYCARDGO_LIBDIR) " :" $( STATUSQ_INSTALL_PATH) /StatusQ " :" $( LD_LIBRARY_PATH) " \
2024-07-12 13:51:06 +00:00
gdb -ex= r ./bin/nim_status_client $( ARGS)
2022-09-14 15:44:15 +00:00
run-macos : nim_status_client
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 ./
2022-09-14 19:47:19 +00:00
./node_modules/.bin/fileicon set bin/nim_status_client status-dev.icns
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/StatusDev.app/Contents/MacOS/nim_status_client"
2023-10-19 18:27:27 +00:00
./bin/StatusDev.app/Contents/MacOS/nim_status_client $( ARGS)
2020-05-14 14:58:08 +00:00
2024-05-17 06:49:51 +00:00
run-windows : STATUS_RC_FILE = status -dev .rc
run-windows : compile_windows_resources nim_status_client $( NIM_WINDOWS_PREBUILT_DLLS )
2023-01-23 13:24:56 +00:00
echo -e "\033[92mRunning:\033[39m bin/nim_status_client.exe"
2024-10-11 15:14:21 +00:00
PATH = " $( DOTHERSIDE_LIBDIR) " :" $( STATUSGO_LIBDIR) " :" $( STATUSKEYCARDGO_LIBDIR) " :" $( STATUSQ_INSTALL_PATH) /StatusQ " :" $( shell pwd ) " /" $( shell dirname " $( NIM_WINDOWS_PREBUILT_DLLS) " ) " :" $( PATH) " \
2023-10-19 18:27:27 +00:00
./bin/nim_status_client.exe $( ARGS)
2020-07-08 16:48:13 +00:00
2023-12-01 19:43:21 +00:00
NIM_TEST_FILES := $( wildcard test/nim/*.nim)
2024-10-21 18:49:17 +00:00
NIM_TESTS := $( foreach test_file,$( NIM_TEST_FILES) ,nim-test-run/$( test_file) )
2023-12-01 19:43:21 +00:00
2024-10-30 12:53:33 +00:00
nim-test-run/% : | dotherside $( STATUSGO )
LD_LIBRARY_PATH = " $( QT5_LIBDIR) " :" $( STATUSGO_LIBDIR) " :" $( LD_LIBRARY_PATH) " $( ENV_SCRIPT) \
nim c $( NIM_PARAMS) $( NIM_EXTRA_PARAMS) --passL:" -L $( STATUSGO_LIBDIR) " --passL:"-lstatus" -r $( subst nim-test-run/,,$@ )
2024-10-21 18:49:17 +00:00
tests-nim-linux : $( NIM_TESTS )
2022-12-19 18:55:40 +00:00
2020-05-14 14:58:08 +00:00
e n d i f # "variables.mk" was not included
