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 \
2020-06-04 20:56:44 +00:00
bottles \
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
check-pkg-target-linux \
check-pkg-target-macos \
check-pkg-target-windows \
2020-05-14 14:58:08 +00:00
clean \
deps \
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 \
2020-06-18 16:44:22 +00:00
status-go \
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
# 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 )
2021-04-13 19:03:19 +00:00
CFLAGS := -mmacosx-version-min= 10.14
2020-06-04 20:56:44 +00:00
export CFLAGS
2021-04-13 19:03:19 +00:00
CGO_CFLAGS := -mmacosx-version-min= 10.14
2020-07-08 16:48:13 +00:00
export CGO_CFLAGS
2020-08-06 21:14:06 +00:00
LIBSTATUS_EXT := dylib
2021-04-13 19:03:19 +00:00
MACOSX_DEPLOYMENT_TARGET := 10.14
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
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
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 )
bottles/openssl :
./scripts/fetch-brew-bottle.sh openssl
2020-06-04 20:56:44 +00:00
2021-04-16 17:36:53 +00:00
bottles/pcre : bottles /openssl
2021-04-15 21:14:30 +00:00
./scripts/fetch-brew-bottle.sh pcre
2020-06-04 20:56:44 +00:00
2021-09-16 15:53:06 +00:00
bottles/hunspell : bottles /pcre
2021-09-10 12:47:07 +00:00
./scripts/fetch-brew-bottle.sh hunspell
2021-09-16 15:53:06 +00:00
bottles : bottles /hunspell
2021-04-15 21:14:30 +00:00
e n d i f
2020-06-04 20:56:44 +00:00
2020-07-08 16:48:13 +00:00
deps : | deps -common bottles
2020-05-14 14:58:08 +00:00
2020-07-08 16:48:13 +00:00
update : | update -common
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 )
QT5_PCFILEDIR := $( shell pkg-config --variable= pcfiledir Qt5Core 2>/dev/null)
QT5_LIBDIR := $( shell pkg-config --variable= libdir Qt5Core 2>/dev/null)
ifeq ( $( QT5_PCFILEDIR) ,)
ifeq ( $( QTDIR) ,)
$( error Cannot find your Qt5 installation. Please run " $( MAKE) QTDIR=/path/to/your/Qt5/installation/prefix ... " )
2020-05-25 02:18:37 +00:00
else
2020-06-25 21:04:47 +00:00
QT5_PCFILEDIR := $( QTDIR) /lib/pkgconfig
QT5_LIBDIR := $( QTDIR) /lib
2020-07-08 16:48:13 +00:00
# some manually installed Qt5 instances have wrong paths in their *.pc files, so we pass the right one to the linker here
ifeq ( $( detected_OS) ,Darwin)
NIM_PARAMS += -L:"-framework Foundation -framework Security -framework IOKit -framework CoreServices"
# Fix for failures due to 'can't allocate code signature data for'
NIM_PARAMS += --passL:"-headerpad_max_install_names"
NIM_PARAMS += --passL:" -F $( QT5_LIBDIR) "
2021-09-10 12:47:07 +00:00
HUNSPELL := bottles/hunspell/lib/libhunspell-1.7.a
NIM_PARAMS += --passL:" $( HUNSPELL) "
2020-07-08 16:48:13 +00:00
export QT5_LIBDIR
else
NIM_PARAMS += --passL:" -L $( QT5_LIBDIR) "
endif
2020-05-25 02:18:37 +00:00
endif
endif
2020-07-08 16:48:13 +00:00
DOTHERSIDE := vendor/DOtherSide/build/lib/libDOtherSideStatic.a
DOTHERSIDE_CMAKE_PARAMS := -DENABLE_DYNAMIC_LIBS= OFF -DENABLE_STATIC_LIBS= ON
# order matters here, due to "-Wl,-as-needed"
NIM_PARAMS += --passL:" $( DOTHERSIDE) " --passL:" $( shell PKG_CONFIG_PATH = " $( QT5_PCFILEDIR) " pkg-config --libs Qt5Core Qt5Qml Qt5Gui Qt5Quick Qt5QuickControls2 Qt5Widgets Qt5Svg) "
e l s e
DOTHERSIDE := vendor/DOtherSide/build/lib/Release/DOtherSide.dll
DOTHERSIDE_CMAKE_PARAMS := -T"v141" -A x64 -DENABLE_DYNAMIC_LIBS= ON -DENABLE_STATIC_LIBS= OFF
NIM_PARAMS += -L:$( DOTHERSIDE)
NIM_EXTRA_PARAMS := --passL:"-lsetupapi -lhid"
2020-05-25 02:18:37 +00:00
e n d i f
2021-05-27 22:32:33 +00:00
DOTHERSIDE_BUILD_CMD := cmake --build . --config Release $( HANDLE_OUTPUT)
2020-05-14 14:58:08 +00:00
feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes #2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
RELEASE ?= false
i f e q ( $( RELEASE ) , f a l s e )
# 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
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) `
NIM_PARAMS += -d:DESKTOP_VERSION= " $( DESKTOP_VERSION) "
2020-05-14 14:58:08 +00:00
$(DOTHERSIDE) : | deps
echo -e $( BUILD_MSG) "DOtherSide"
+ cd vendor/DOtherSide && \
2020-06-04 20:56:44 +00:00
mkdir -p build && \
cd build && \
2020-05-25 02:18:37 +00:00
rm -f CMakeCache.txt && \
2020-07-08 16:48:13 +00:00
cmake $( DOTHERSIDE_CMAKE_PARAMS) \
2020-06-18 16:44:22 +00:00
-DCMAKE_BUILD_TYPE= Release \
-DENABLE_DOCS= OFF \
-DENABLE_TESTS= OFF \
.. $( HANDLE_OUTPUT) && \
2020-07-08 16:48:13 +00:00
$( DOTHERSIDE_BUILD_CMD)
2020-05-14 14:58:08 +00:00
2020-08-06 21:14:06 +00:00
STATUSGO := vendor/status-go/build/bin/libstatus.$( LIBSTATUS_EXT)
STATUSGO_LIBDIR := $( shell pwd ) /$( shell dirname " $( STATUSGO) " )
export STATUSGO_LIBDIR
2020-05-14 20:19:01 +00:00
2020-06-18 16:44:22 +00:00
status-go : $( STATUSGO )
2020-05-14 20:19:01 +00:00
$(STATUSGO) : | deps
echo -e $( BUILD_MSG) "status-go"
+ cd vendor/status-go && \
2020-08-06 21:14:06 +00:00
$( MAKE) statusgo-shared-library $( HANDLE_OUTPUT)
2020-05-14 14:58:08 +00:00
2020-06-23 17:17:58 +00:00
QRCODEGEN := vendor/QR-Code-generator/c/libqrcodegen.a
$(QRCODEGEN) : | deps
echo -e $( BUILD_MSG) "QR-Code-generator"
+ cd vendor/QR-Code-generator/c && \
2020-07-08 16:48:13 +00:00
$( MAKE) $( QRCODEGEN_MAKE_PARAMS)
2020-06-23 17:17:58 +00:00
2020-12-10 16:56:32 +00:00
FLEETS := fleets.json
$(FLEETS) :
echo -e $( BUILD_MSG) " Getting latest $( FLEETS) "
2020-11-03 19:42:55 +00:00
curl -s https://fleets.status.im/ \
| jq --indent 4 --sort-keys . \
2020-12-10 16:56:32 +00:00
> $( FLEETS)
2020-11-03 19:42:55 +00:00
2020-12-10 16:56:32 +00:00
fleets-remove :
rm -f $( FLEETS)
2020-11-06 15:50:58 +00:00
2020-12-10 16:56:32 +00:00
fleets-update : fleets -remove $( FLEETS )
2020-10-30 01:53:34 +00:00
2020-06-30 21:35:24 +00:00
rcc :
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
2020-10-30 01:53:34 +00:00
# default token is a free-tier token with limited capabilities and usage
# limits; our docs should include directions for community contributor to setup
# their own Infura account and token instead of relying on this default token
# during development
DEFAULT_TOKEN := 220a1abb4b6943a093c35d0ce4fb0732
INFURA_TOKEN ?= $( DEFAULT_TOKEN)
NIM_PARAMS += -d:INFURA_TOKEN:" $( INFURA_TOKEN) "
2021-07-21 08:26:31 +00:00
DEFAULT_TENOR_API_KEY := DU7DWZ27STB2
TENOR_API_KEY ?= $( DEFAULT_TENOR_API_KEY)
NIM_PARAMS += -d:TENOR_API_KEY:" $( TENOR_API_KEY) "
2021-09-14 19:39:29 +00:00
NIM_PARAMS += -d:chronicles_sinks= textlines[ stdout] ,textlines[ nocolors,dynamic] ,textlines[ file,nocolors] -d:chronicles_runtime_filtering= on -d:chronicles_default_output_device= dynamic
2021-06-29 18:42:18 +00:00
feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes #2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
RESOURCES_LAYOUT := -d:development
nim_status_client : NIM_PARAMS += $( RESOURCES_LAYOUT )
2020-12-10 16:56:32 +00:00
nim_status_client : | $( DOTHERSIDE ) $( STATUSGO ) $( QRCODEGEN ) $( FLEETS ) rcc deps
2020-05-14 14:58:08 +00:00
echo -e $( BUILD_MSG) " $@ " && \
2020-08-06 21:14:06 +00:00
$( ENV_SCRIPT) nim c $( NIM_PARAMS) --passL:" -L $( STATUSGO_LIBDIR) " --passL:"-lstatus" $( NIM_EXTRA_PARAMS) --passL:" $( QRCODEGEN) " --passL:"-lm" src/nim_status_client.nim && \
2020-09-03 16:06:36 +00:00
[ [ $$ ? = 0 ] ] && \
( ( [ [ $( detected_OS) = Darwin ] ] && \
2020-08-06 21:14:06 +00:00
install_name_tool -change \
libstatus.dylib \
@rpath/libstatus.dylib \
2020-09-03 16:06:36 +00:00
bin/nim_status_client) || true )
2020-05-14 20:19:01 +00:00
2020-06-04 20:56:44 +00:00
_APPIMAGE_TOOL := appimagetool-x86_64.AppImage
APPIMAGE_TOOL := tmp/linux/tools/$( _APPIMAGE_TOOL)
$(APPIMAGE_TOOL) :
2020-07-08 16:48:13 +00:00
echo -e "\e[92mFetching:\e[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)
2020-06-04 20:56:44 +00:00
mv $( _APPIMAGE_TOOL) tmp/linux/tools/
chmod +x $( APPIMAGE_TOOL)
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
feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes #2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
$(STATUS_CLIENT_APPIMAGE) : override RESOURCES_LAYOUT := -d :production
2020-06-18 16:44:22 +00:00
$(STATUS_CLIENT_APPIMAGE) : nim_status_client $( APPIMAGE_TOOL ) nim -status .desktop
2020-06-04 20:56:44 +00:00
rm -rf pkg/*.AppImage
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
rm -rf tmp/linux/dist
2020-06-04 20:56:44 +00:00
mkdir -p tmp/linux/dist/usr/bin
mkdir -p tmp/linux/dist/usr/lib
mkdir -p tmp/linux/dist/usr/qml
2020-05-18 16:51:29 +00:00
2020-05-15 13:00:49 +00:00
# General Files
2020-06-04 20:56:44 +00:00
cp bin/nim_status_client tmp/linux/dist/usr/bin
cp nim-status.desktop tmp/linux/dist/.
cp status.svg tmp/linux/dist/status.svg
2020-06-30 21:35:24 +00:00
cp status.svg tmp/linux/dist/usr/.
cp -R resources.rcc tmp/linux/dist/usr/.
2020-12-10 16:56:32 +00:00
cp -R $( FLEETS) tmp/linux/dist/usr/.
2020-08-10 20:19:15 +00:00
mkdir -p tmp/linux/dist/usr/i18n
cp ui/i18n/* tmp/linux/dist/usr/i18n
2020-05-15 13:00:49 +00:00
2020-08-06 21:14:06 +00:00
# Libraries
2020-10-07 15:24:24 +00:00
cp -r /usr/lib/x86_64-linux-gnu/nss tmp/linux/dist/usr/lib/
2021-04-21 20:13:21 +00:00
cp -P /usr/lib/x86_64-linux-gnu/libgst* tmp/linux/dist/usr/lib/
cp -r /usr/lib/x86_64-linux-gnu/gstreamer-1.0 tmp/linux/dist/usr/lib/
cp -r /usr/lib/x86_64-linux-gnu/gstreamer1.0 tmp/linux/dist/usr/lib/
2020-08-06 21:14:06 +00:00
cp vendor/status-go/build/bin/libstatus.so tmp/linux/dist/usr/lib/
2020-05-14 20:19:01 +00:00
echo -e $( BUILD_MSG) "AppImage"
2020-08-12 15:01:03 +00:00
linuxdeployqt tmp/linux/dist/nim-status.desktop -no-copy-copyright-files -qmldir= ui -qmlimport= $( QTDIR) /qml -bundle-non-qt-libs
2020-06-04 20:56:44 +00:00
rm tmp/linux/dist/AppRun
cp AppRun tmp/linux/dist/.
mkdir -p pkg
2020-06-18 16:44:22 +00:00
$( APPIMAGE_TOOL) tmp/linux/dist $( STATUS_CLIENT_APPIMAGE)
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) :
2020-07-08 16:48:13 +00:00
echo -e "\e[92mInstalling:\e[39m create-dmg"
2020-06-04 20:56:44 +00:00
npm i
2020-05-15 13:00:49 +00:00
2020-09-22 15:12:48 +00:00
MACOS_OUTER_BUNDLE := tmp/macos/dist/Status.app
MACOS_INNER_BUNDLE := $( MACOS_OUTER_BUNDLE) /Contents/Frameworks/QtWebEngineCore.framework/Versions/Current/Helpers/QtWebEngineProcess.app
2020-05-14 20:19:01 +00:00
2020-06-18 16:44:22 +00:00
STATUS_CLIENT_DMG ?= pkg/Status.dmg
2020-06-04 20:56:44 +00:00
feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes #2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
$(STATUS_CLIENT_DMG) : override RESOURCES_LAYOUT := -d :production
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/
2020-12-10 16:56:32 +00:00
cp -R $( FLEETS) $( MACOS_OUTER_BUNDLE) /Contents/
2020-09-22 15:12:48 +00:00
mkdir -p $( MACOS_OUTER_BUNDLE) /Contents/i18n
cp ui/i18n/* $( MACOS_OUTER_BUNDLE) /Contents/i18n
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
2020-09-22 15:12:48 +00:00
scripts/sign-macos-pkg.sh $( MACOS_OUTER_BUNDLE) $( MACOS_CODESIGN_IDENT)
scripts/sign-macos-pkg.sh $( MACOS_INNER_BUNDLE) $( MACOS_CODESIGN_IDENT) \
--entitlements QtWebEngineProcess.plist
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
2021-05-27 07:53:40 +00:00
notarize-macos : export CHECK_INTERVAL_SEC ?= 30
notarize-macos : export CHECK_RETRY_LIMIT ?= 20
notarize-macos : export MACOS_BUNDLE_ID ?= im .status .ethereum .desktop
notarize-macos :
scripts/notarize-macos-pkg.sh $( STATUS_CLIENT_DMG)
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
NIM_WINDOWS_PREBUILT_DLLS ?= tmp/windows/tools/pcre.dll
$(NIM_WINDOWS_PREBUILT_DLLS) :
echo -e "\e[92mFetching:\e[39m prebuilt DLLs from nim-lang.org"
rm -rf tmp/windows
mkdir -p tmp/windows/tools
cd tmp/windows/tools && \
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
2021-07-15 11:12:18 +00:00
$(STATUS_CLIENT_EXE) : override RESOURCES_LAYOUT := -d :production
$(STATUS_CLIENT_EXE) : OUTPUT := tmp /windows /dist /Status
$(STATUS_CLIENT_EXE) : INSTALLER_OUTPUT := pkg
$(STATUS_CLIENT_EXE) : nim_status_client nim_windows_launcher $( NIM_WINDOWS_PREBUILT_DLLS )
rm -rf pkg/*.exe tmp/windows/dist
2021-04-19 14:45:46 +00:00
mkdir -p $( OUTPUT) /bin $( OUTPUT) /resources $( OUTPUT) /vendor $( OUTPUT) /resources/i18n
cat windows-install.txt | unix2dos > $( OUTPUT) /INSTALL.txt
cp status.ico status.svg resources.rcc $( FLEETS) $( OUTPUT) /resources/
cp ui/i18n/* $( OUTPUT) /resources/i18n
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
cp $( DOTHERSIDE) $( STATUSGO) tmp/windows/tools/*.dll $( OUTPUT) /bin/
cp " $( shell which libgcc_s_seh-1.dll) " $( OUTPUT) /bin/
cp " $( shell which libwinpthread-1.dll) " $( OUTPUT) /bin/
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
echo -e $( BUILD_MSG) "deployable folder"
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 07:44:36 +00:00
echo -e $( BUILD_MSG) "7z"
rm $( OUTPUT) /status.iss
2021-09-15 08:31:45 +00:00
7z a $( INSTALLER_OUTPUT) /$( STATUS_CLIENT_7Z) ./$( OUTPUT)
2020-07-08 16:48:13 +00:00
2020-06-04 20:56:44 +00:00
pkg : $( PKG_TARGET )
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
pkg-linux : check -pkg -target -linux $( STATUS_CLIENT_APPIMAGE )
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
2020-05-14 14:58:08 +00:00
clean : | clean -common
2021-04-15 21:14:30 +00:00
rm -rf bin/* node_modules bottles/* pkg/* tmp/* $( STATUSGO)
2020-06-04 20:56:44 +00:00
+ $( MAKE) -C vendor/DOtherSide/build --no-print-directory clean
2020-07-08 16:48:13 +00:00
run : rcc $( RUN_TARGET )
2021-01-19 16:10:36 +00:00
ICON_TOOL := node_modules/.bin/fileicon
$(ICON_TOOL) :
echo -e "\e[92mInstalling:\e[39m fileicon"
npm i
feat: command-line option can be used to specify app's data directory
In the repo:
```
$ bin/nim_status_client --help
```
In the packaged app (macOS example):
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --help
```
Output:
```
Usage:
nim_status_client [OPTIONS]...
The following options are available:
-d, --dataDir Status Desktop data directory.
```
**Using the option**
```
$ cd ~/status-ci-builds/master/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/master"
```
In another terminal:
```
$ cd ~/status-ci-builds/PR-4242/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir:"${HOME}/status-dirs/PR-4242"
```
The path supplied can be relative or absolute, and can be specified with
`--dataDir:[path]`, `--dataDir=[path]`, `-d:[path]`, or `-d=[path]`.
Either `:` or `=` must be used, i.e. this *will not* work: `--dataDir [path]`
or `-d [path]`.
The name of the option follows Nim's partial case-insensitivity rules, so
`--dataDir`, `--datadir`, and `--data_dir` are all equivalent. See
[Identifier equality][ieq] in the Nim Manual.
It is possible to run the same build in multiple terminals by supplying
different `--dataDir`, i.e. this works:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some1"
```
In another terminal:
```
$ cd /Applications/Status.app/Contents/MacOS
$ ./nim_status_client --dataDir="${HOME}/temp/some2"
```
**Windows**
It is recommended to use a Git Bash or MSYS2 terminal when invoking
`bin/nim_status_client.exe` (development build) or `bin/Status.exe` (production
build) on the command-line. The reason is that if the exe is invoked in a
session of `cmd.exe` it will return to the prompt immediately; the app will run
but there will be no output in the terminal. In any case, the `--dataDir`
option will take effect whether the exe is invoked in `cmd.exe` or a
recommended terminal.
For development builds, when invoking `bin/nim_status_client.exe` directly
instead of via `make run`, because e.g. you wish to use the `--dataDir` option,
it is required to first setup the `PATH` environment variable correctly. See
the `run-windows` target in this repo's Makefile for more information.
**Linux**
The `--dataDir` option may be passed to command-line invocation of a
production (AppImage) build in the same way as passing it to a development
build:
```
$ Status.AppImage --dataDir:/path/to/wherever
```
For development builds, when invoking `bin/nim_status_client` directly instead
of via `make run`, because e.g. you wish to use the `--dataDir` option, it is
required to setup the `LD_LIBRARY_PATH` environment variable correctly. See the
`run-linux` target in this repo's Makefile for more information.
---
BREAKING CHANGE: The `qt` subdir of the app's data directory is now a sibling
of the status-go directory rather than a subdir of the status-go directory:
```
Status (app data directory)
├── data (status-go directory)
├── qt
└── tmp
```
Because app settings are stored in the `qt` directory that means that existing
installations will lose their customized settings.
At app startup, it would be possible to detect `Status/data/qt` and if
`Status/qt` doesn't exist yet then copy `Status/data/qt` to
`Status/qt`. However, there was some concern that behavior could lead to
problems later on if we forget the workaround is in place. So for now that
settings preservation strategy has not been implemented, but it might be before
this commit is merged pending full team awareness/consensus.
---
Command-line option support is provided by
[nim-confutils](https://github.com/status-im/nim-confutils).
The environment variable `NIM_STATUS_CLIENT_DEV` has been removed in favor of
passing a "define" option to the Nim compiler: `-d:development` for development
builds (e.g. `make V=1`) and `-d:production` for packaged builds (e.g. `make
V=1 pkg`). Passing the correct option is handled automatically by the Makefile.
A make variable named `RELEASE` has been introduced, which defaults to
`false`. Presently the `RELEASE` variable should not be set on the command-line
nor in CI as more work needs to be done to toggle the proper compiler flags. In
the case of Status Desktop, "release vs. debug" is a concern orthogonal to
"production vs. development". At present, production builds and development
builds are all debug builds, but that will likely change in the future: we can
have non-release CI production builds and local development builds be debug
builds, while release builds in CI would be production builds with
`RELEASE=true` (the compiled executable will be fully optimized).
Prior to the changes in this PR, symmetry is somewhat lacking between
development and production (packaged) builds with respect to the concept of the
"data directory". In development builds the root of the repo effectively serves
as the `Status` directory used by production builds, e.g. on macOS
`~/Library/Application Support/Status`. Also, there's a bit of confusion as to
whether "data directory" refers to a directory for the desktop app's overall
data (including status-go data) or to the specific directory used by status-go.
This PR attempts to provide symmetry and reduce confusion:
* The term "data directory" means the directory used by the desktop app to
store multiple kinds of data and is not a reference to the subdirectory used by
status-go.
* For development builds the "data directory" defaults to `./Status/` relative
to the root of the repo.
* For production builds the "data directory" default is the same as before,
e.g. on macOS it's ` ~/Library/Application Support/Status/`.
The directory used by status-go is `Status/data/`. To be clear, that should be
referred to as the "status-go directory" and not the app's "data directory". It
would nice if we could rename it from `Status/data/` to `Status/status-go/`. We
can do that, I already checked that it works correctly; however, for existing
installations it would require that at app launch we check for the presence of
`Status/data/` and rename it to `Status/status-go`. While simple enough to do,
I was concerned that there might be edge cases where the directory rename could
cause a problem (e.g. if another copy of the app is running) so chose for now
to stick with the status-go directory being `Status/data/`.
---
**NOTES**
More work needs to be done to ensure that all data written by the app is
contained in the default or cli-specified data directory. Currently, both
development and production (packaged) builds are writing to common directories
outside of the data directory, e.g. located within `~/Library/` on
macOS. Changing that behavior seems like it will mainly involve changing
defaults related to Qt components such as the web engine. See:
https://github.com/status-im/status-desktop/issues/1141.
In general, additional refactoring could be done in the future. For
example, implementing `StatusDesktopConfig` in
`src/status/libstatus/accounts/constants.nim` (as done in this PR) works fine
for now, but better code organization is desirable.
---
Closes #2268
[ieq]: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
2021-04-19 12:20:07 +00:00
# Currently not in use: https://github.com/status-im/status-desktop/pull/1858
# STATUS_PORT ?= 30306
2020-07-03 19:22:15 +00:00
2020-08-06 21:14:06 +00:00
run-linux :
echo -e "\e[92mRunning:\e[39m bin/nim_status_client"
LD_LIBRARY_PATH = " $( QT5_LIBDIR) " :" $( STATUSGO_LIBDIR) " \
./bin/nim_status_client
2021-04-30 18:58:55 +00:00
run-macos : $( ICON_TOOL )
mkdir -p bin/StatusDev.app/Contents/{ MacOS,Resources}
cp Info.dev.plist bin/StatusDev.app/Contents/Info.plist
cp status-dev.icns bin/StatusDev.app/Contents/Resources/
cd bin/StatusDev.app/Contents/MacOS && \
ln -fs ../../../nim_status_client ./
npx fileicon set bin/nim_status_client status-dev.icns
echo -e "\e[92mRunning:\e[39m bin/StatusDev.app/Contents/MacOS/nim_status_client"
./bin/StatusDev.app/Contents/MacOS/nim_status_client
2020-05-14 14:58:08 +00:00
build: implement packaging steps for the Windows build
Implement a `pkg-windows` target that ultimately results in `Status.zip` being
written to `pkg/`.
Note: this commit does not introduce code signing for the Windows build since
that piece is still a work in progress.
`pkg-windows` creates a portable folder in `tmp/windows/dist` with the help of
[`windeployqt`][windeployqt], which copies the needed portions of Qt into the
folder.
Since DLL resolution is relatively inflexible, a launcher `Status.exe` is
created at the top-level of the folder; the launcher opens `bin/Status.exe`
while adding the portable folder's `bin/` to the `PATH`, allowing
`bin/Status.exe` to resolve the DLLs in that folder.
A few additional tools need to be installed (e.g. with [scoop][scoop]) and
availble in `PATH`:
* 7-zip
* dos2unix (provides unix2dos)
* findutils
* go
* rcedit
* wget
The above list builds on the tools list in PR #521, and the other requirements
and instructions in that PR's description still apply.
**Why not build an installer?**
When starting work on packaging for the Windows build, my initial plan was to
build an installer, and for that purpose I researched the [WiX Toolset][wix],
the [Qt Installer Framework][qtif], and some other options.
I found that building an installer is a bit complex. I then recalled, from
personal experience, that [Cmder][cmder]'s [Mini download][mini] is
installer-less. You simply unzip the download and place the `cmder_mini` folder
wherever you prefer. Such an approach was also recommended to me in one of the
Nim language's community chats.
In addition to being simpler, the installer-less approach also gives
installation of Status Desktop a lower profile than an installer-application
would since nothing is written to the Windows registry, added to the *Add or
remove programs* list, etc. I think that's a benefit given the privacy-security
focus of Status, but others may feel differently so please provide feedback on
this point!
[windeployqt]: https://doc.qt.io/qt-5/windows-deployment.html
[scoop]: https://scoop.sh/
[wix]: https://wixtoolset.org/
[qtif]: https://doc.qt.io/qtinstallerframework/index.html
[cmder]: https://cmder.net/
[mini]: https://github.com/cmderdev/cmder/releases/download/v1.3.15/cmder_mini.zip
2020-07-15 22:45:56 +00:00
run-windows : $( NIM_WINDOWS_PREBUILT_DLLS )
2020-07-08 16:48:13 +00:00
echo -e "\e[92mRunning:\e[39m bin/nim_status_client.exe"
2020-08-06 21:14:06 +00:00
PATH = " $( shell pwd ) " /" $( shell dirname " $( DOTHERSIDE) " ) " :" $( STATUSGO_LIBDIR) " :" $( shell pwd ) " /" $( shell dirname " $( NIM_WINDOWS_PREBUILT_DLLS) " ) " :" $( PATH) " \
2020-07-03 19:22:15 +00:00
./bin/nim_status_client.exe
2020-07-08 16:48:13 +00:00
2020-05-14 14:58:08 +00:00
e n d i f # "variables.mk" was not included
