Commit Graph

51 Commits

Author SHA1 Message Date
Michael Bradley, Jr 89e42f960d build: modify run logic for macOS dev builds so notifications work 2021-05-03 14:06:14 -04:00
Jakub Sokołowski 089ee7ee80 ci: scripts/sign-windows-bin.sh for signing Windows binaries
This introduces the `scripts/sign-windows-bin.sh` script which is used
by the `Makefile` to sign application libraries and executables. It also
implements the logic necessary to distinguish between different types of
builds: release and non-release builds.

Some other changes:

* Refactore the `Makefile` target that creates the Windows ZIP to make less verbose.
* Added `Microsoft.VisualStudio.Component.Windows10SDK.10240` to VisualStudio component
* Added `BUILD_TYPE` parameter to `Jenkinsfile`s for different platform builds

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-28 18:19:17 +02:00
Michael Bradley, Jr 02b26f3c28 build: launch nim_status_client directly in packaged builds for macOS
Remove the `nim_status_client.sh` launcher script and make related changes.
2021-04-28 07:15:44 -05:00
Michael Bradley, Jr 37c51cc25f build: use same container as Jenkins CI for local packaged builds on Linux
Make the docker-related logic for doing a local packaged build on Linux match
with the Jenkins CI build for Linux.

Also fix the problems with packaged builds for Linux (local or CI) where
gstreamer errors were displayed in the terminal shortly after app start/login
and there was no sound output.
2021-04-27 13:49:46 -05:00
Michael Bradley, Jr c03a086c01 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-26 09:40:58 -05:00
Michael Bradley, Jr 7eda54a141 fix: don't run scripts/fetch-brew-bottle.sh in parallel
It's not supported to run `brew update` multiple times simultaenously. A better
fix for this can be implemented, but for now in the Makefile have target
`bottles/pcre` depend on target `bottles/openssl` so that they run serially
when `-jN` is passed to `make`.

I was originally going to change `brew update >/dev/null` to
`brew update >/dev/null || true` but decided the Makefile change provides a
better guarantee that simultaenous `brew` commands won't interfere with each
other. In the process, I revised some of the script's `echo` output just a bit.
2021-04-16 13:16:44 -05:00
Michael Bradley, Jr c5f74ac2c0 build: use GitHub credentials when downloading bottles for macOS
Signed-off-by: Jakub Sokołowski <jakub@status.im>
2021-04-16 10:52:06 -05:00
Michael Bradley, Jr 0832cef36b build: fetch macOS Homebrew bottles from GitHub Packages instead of bintray
bintray (for open source) is shutting down permanently on May 1:

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

At this time downloading from GitHub Packages requires specifying a username
and personal acccess token, but it seems they don't have to be valid. For
example, in the changes to the Makefile I specified `_:_` as the username and
token.

Also, change the minimum macOS version from 10.13 to 10.14 since Homebrew
bottles are no longer built for 10.13 (High Sierra):

https://github.com/Homebrew/discussions/discussions/1264#discussioncomment-601544

Closes #1851
2021-04-14 15:37:53 -04:00
Michael Bradley, Jr 0a77bedb15 chore: revise how dev version of app icon is set on macOS during `make run`
The way it was done previously didn't always produce the intended result (for
unknown reasons), i.e. the dev app would sometimes launch with a transparent
blank square appearing in place of the expected icon.
2021-01-21 15:36:32 -06:00
Michael Bradley, Jr 05f38fa966 chore: refactor prod/dev app icon and related logic for macOS 2021-01-15 19:12:42 -05:00
Michael Bradley, Jr 13daa540e4 build: use a different colored app icon and a non-default STATUS_PORT for dev builds
By default the desktop app uses port 30305, unless a value is specifically set
in environment variable `STATUS_PORT`. For convenience of those developing the
app and running development builds, while simultaneously running production
builds (a.k.a. packaged builds, whether built locally or in CI), have `make
run` invoke `bin/nim_status_client` with `STATUS_PORT=30306`. That value can
still be overriden by manually invoking `make run` with a different value,
e.g. `make STATUS_PORT=30307 run` and `STATUS_PORT=30307 make run` are both
valid and achieve the same effect. NOTE: the port "sticks" in the database
after the first clean run, so when changing ports developers will need to
delete the data dir within their local repository, else the existing database
for dev builds will be stuck using whatever port was used previously. In the
future, we can figure out a means to always update the port setting in the
database just after the login event (but see #1505).

Also, for development builds use an icon (for the running app) that is
orangered (`#ff4500`) instead of the official blue color. This makes it much
easier to select between a running production instance and development instance
when Cmd-Tab'ing (on macOS, or equiv on Linux and Windows) through open
applications. Not all icons displayed at runtime have been changed in this
manner for development builds, just the main application icon, and that seems
to be sufficient to achieve the desired effect; though in the future we could
do similar for notification icon, menu bar icon, etc.
2020-12-18 15:37:06 -05:00
Michael Bradley, Jr 8de3a3f48f refactor: in Windows packaged build fleets.json should be in resources/
In the context of Windows packaged builds, this is consistent with other
resources needed by the application; organizing them in this way keeps the
top-level directory of Windows packaged builds clear of files that most users
should never have to see or think about.
2020-12-10 12:03:39 -06:00
Michael Bradley, Jr 10d82124fe refactor: embed Infura key at compile time
Allow environmental override at runtime. Also, in the Makefile set a free-tier
default token so that setting up an Infura account isn't strictly necessary for
community contributors to build the app, even though in our docs it should be
recommended they do so.

Core contributors should setup their own free-tier Infura account, create a
key, and set it in the environment variable INFURA_TOKEN in their environment
used to build the desktop app locally.

There is one aspect of this work that is incomplete. Ideally, in the handler
for the `login` event the relevant settings in the database should always be
updated with the resolved Infura key. However, when calling
`getSetting[string](Setting.Networks_Networks)` in the handler it causes a
segfault every time. Neither the reason for the crash nor a workaround have
been worked out at this time.
2020-12-09 12:10:12 -06:00
Jonathan Rainville 0e874d8745 fix: fix fleets.json file wrongly placed in Windows builds 2020-11-26 11:45:25 -05:00
Jacek Sieka fa3aa77ee5 rcc: single dash options
According to help, options are single-dash - in fact, the default `rcc`
on fedora doesn't accept double-dash.
2020-11-26 11:17:47 -05:00
Richard Ramos cd8f49921f Update docker linux version 2020-11-06 16:22:07 -05:00
Richard Ramos aec77b65df feat: use fleets.json to set the node config 2020-11-05 10:52:56 -05:00
Richard Ramos 48fed85121 test: copying nss libs 2020-10-20 14:42:36 -04:00
Michael Bradley, Jr e985e99f36 feat: reintroduce the dapp browser 2020-10-20 14:42:36 -04:00
Jakub Sokołowski e7c428d3e2 makefile: fix filename of resulting windows zip
Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-09-29 15:11:27 +02:00
Michael Bradley, Jr f6b1f31326 build: don't swallow error when make fails to build bin/nim_status_client 2020-09-03 11:27:25 -05:00
Michael Bradley, Jr 507f510c62 build: dynamically link to status-go built as a shared library 2020-08-28 12:32:49 -04:00
Jonathan Rainville 72af6adb69 feat: get and display emoji reactions in chat 2020-08-27 16:34:35 -04:00
Michael Bradley, Jr c08767c74b build: remove dapp browser 2020-08-17 14:01:26 -04:00
Jonathan Rainville 9466714d90 change path to resources 2020-08-11 17:51:35 -04:00
Jonathan Rainville 24ddb7852c fix Mac i18n location 2020-08-11 17:51:35 -04:00
Jonathan Rainville acc067d536 fix: make packaged translations work 2020-08-11 17:51:35 -04:00
Michael Bradley, Jr e0852d2f73 build: implement code signing step for the Windows build
Add a code signing step to the `pkg-windows` target. If the environment
variable `WINDOWS_CODESIGN_PFX_PATH` is not set then code signing is
skipped. If the environment variable `WINDOWS_CODESIGN_TIMESTAMP_URL` is not
set then a verified timestamp will not be included in the signature. Both
variables should be set in production/CI builds.

Signing is performed with Window's [SignTool][signtool]. There is a helpful
[Stack Overflow answer][soa] which explains how to easily setup a self-signed
CA and code signing certificate and then use them with `signtool`, which is how
I tested these changes on my local Windows machine.

Absolute paths are used for `egrep`, `xargs`, and `bash` to avoid accidentally
running other installations of those executables than the ones that ship with
Git Bash. I was experiencing mysterious failures in the sequence of commands
and then noticed that e.g. `which xargs` was resolving to an executable in
`${HOME}/scoop/shims`.

I tested locally that the signed DLLs and EXEs run correctly on Windows 7 and
Windows 10.

For CI builds Status will need to acquire a signing certificate from
e.g. DigiCert. There will be a yearly renewal cost.

In researching what files should be signed, I concluded that it only makes
sense to sign `.dll` and `.exe` files. It's possible to generate signatures for
other file types but the signatures would have to be stored apart from those
files, unlike `.dll` and `.exe` where the signature is embedded in the
executable. Also, it doesn't seem to be possible to embed a signature in a
`.zip` file, though it would be possible to sign the compressed package if we
chose to build and distribute a self-extracting `Status.exe` instead of
`Status.zip`.

If a DLL or EXE file is already validly signed, e.g. the Qt DLLs, `signtool.exe
sign` is not invoked on that file.

Closes #288.

[signtool]: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool
[soa]: https://stackoverflow.com/a/201277
2020-07-22 10:37:57 -04:00
Michael Bradley, Jr 29e74b6b3f 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-17 13:57:32 -05:00
Michael Bradley, Jr b22b500d4f refactor: store data folder in OS appropriate location
If the environment variable `NIM_STATUS_CLIENT_DEV` is not empty then the
`./data` dir is created/used relative to the current working directory, as was
always the case prior to the changes introduced in this commit.

`NIM_STATUS_CLIENT_DEV` is set to `t` when doing `make run`. To get the
production behavior in development do:

```
$ NIM_STATUS_CLIENT_DEV="" make run
```
or on Windows in a Bash shell:
```
$ NIM_STATUS_CLIENT_DEV="" mingw32-make run
```

Closes #391
2020-07-10 16:15:37 -04:00
Michael Bradley, Jr 6150928062 build: enhance build system so that it can run directly on Windows
Replaces #82, which in any case is out-of-date re: the current state of this
repo's Makefile.

Introduces the ability to build `nim_status_client.exe` directly on Windows,
i.e. without needing to use Windows Subsystem for Linux or otherwise
cross-compile on Linux.

Note: this commit does not introduce packaging or code signing for the Windows
build as those pieces are still a work in progress.

The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as
included in the installation of [Git for Windows][git-win].

[Microsoft Visual C++ Build Tools][ms-build] must be installed.

Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be
installed, e.g. with the Qt Online Installer tool.

CMake needs to be installed; it is available via the Qt Online Installer tool
under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`).

A couple of additional tools need to be installed (e.g. with [scoop][scoop])
and availble in `PATH`:
* findutils
* go

For `.dll` resolution to function as needed, in a Bash shell `PATH` should be
modified like this (might be different depending on how/where things were
installed):

```bash
export QTBASE="/c/Qt"
export QTDIR="${QTBASE}/5.14.2/msvc2017_64"

export PATH="${HOME}/scoop/shims:${PATH}"
export PATH="${QTDIR}/bin:${PATH}"
export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}"
export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}"
```

With those modifications in place, to build `nim_status_client.exe` do:
```
mingw32-make.exe V=1
```

To run the executable do:
```
mingw32-make.exe run
```

[git-win]: https://gitforwindows.org/
[ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/
[scoop]: https://scoop.sh/
2020-07-08 12:25:30 -05:00
Michael Bradley, Jr 8f50ccb1ea fix: rm the correct paths for resources.qrc|rcc 2020-07-08 11:36:11 -05:00
Richard Ramos 5b3f077fa9 feat: bundle resources
- Update linux build to package resources
- Refactor macOS packaging re: resources.rcc
2020-07-03 09:59:00 -04:00
Jakub Sokołowski 85a3557f1e add Jenkinsfiles and Dockerfile for CI
Changes:
- Adds `ci/Dockerfile` for creating `statusteam/nim-status-client-build:latest` used in builds
- Adds `ci/Jenkinsfile.linux` and `ci/Jenkinsfile.macos` for respective platforms
- Simplifies MacOS signing by adding `scripts/sign-macos-pkg.sh` script
- Makes `Makefile` use `scripts/sign-macos-pkg.sh` to make the DMG
- Makes `APPIMAGE` and `DMG` in `Makefile` modifiable by environment
- Adds `--passL:"-headerpad_max_install_names"` to `NIM_PARAMS` to fix MacOS signing issues

Signed-off-by: Jakub Sokołowski <jakub@status.im>
2020-07-01 22:06:37 +02:00
Michael Bradley, Jr dfef4374f6 refactor: $QTDIR should include the compiler-arch path segment 2020-06-25 17:29:41 -04:00
Richard Ramos 637484bd79 feat: show qr codes 2020-06-23 18:52:54 -04:00
Michael Bradley, Jr ce7e6b8d51 chore: refactor Linux and macOS build/packaging steps
Replaces PR #105.

Implement a `pkg-macos` target that ultimately results in `Status.dmg` being
written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in
`/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into
`bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible
with macOS 10.13 (the oldest macOS version compatible with Qt v5.14).

`pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on
information in a very helpful [StackOverflow answer][so-answer]. Note the part
of the answer (toward the end) that explains a problem with the working
directory and how to fix it. That's the reason for the `nim_status_client.sh`
script introduced in this commit (it gets copied into the bundle). It's also
the reason for having `Info.plist` copied into the bundle before `macdeployqt`
is run (see below) and then overwriting it with `Info.runner.plist` before
creating the `.dmg` file. The app icons file `status-icon.icns` was taken from
`deployment/macos/` in the [status-react][sr] repo.

The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt
into the bundle; it automatically updates `rpath`, etc. so the
`nim_status_client` executable in the bundle can locate the libs within the
bundle.

`macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles,
because of an apparent bug in `macdeployqt` that results in QtWebEngine related
resources not being processed correctly on the first pass. This results in some
bloat in the final bundle but it seems unavoidable at present.

The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg`
file. There are two reasons for this:
1. It produces a nice looking icon for the `.dmg` that overlays the Status logo
on an external disk icon.
2. `Info.plist` needs to be overwritten after running `macdeployqt` (see
explanation above) but before creating the `.dmg` file. If we passed the `-dmg`
cli option to `macdeployqt` to have it generate the `.dmg` file then it
wouldn't be possible to overwrite `Info.plist`.

So there is a cosmetic reason and a practical reason for using another
tool. Probably the biggest downside is that `create-dmg` is implemented in
Node.js so it needs to be installed with `npm`; that's the reason this commit
introduces `package.json`, etc. Note that zero code from `node_modules` ends up
in the `.app` bundle or the `.dmg` file.

Code signing of the macOS `.app` bundle and `.dmg` is attempted if the
environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the
environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the
path to a preferred keychain database file.

Refactor a number of sections in the Makefile for consistency's sake, e.g. the
`appimage` target becomes `pkg-linux` and ultimately results in
`NimStatusClient-x86_64.AppImage` being written to `pkg/`.

Make a number of changes to bring the Linux packaging steps up-to-date and use
the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt
plugins.

Note that `make pkg` will correctly resolve to `make pkg-linux` or `make
pkg-macos` depending on the OS in use.

Consistently use lower-case "c" in the name of *components* directories and
imports.

[limits]: https://developer.apple.com/forums/thread/124782
[brew]: https://brew.sh/
[so-answer]: https://stackoverflow.com/a/3251285
[sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos
[macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html
[cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-22 10:53:57 -05:00
Ștefan Talpalaru 4fe6d9b767 build system refactoring
- unify the "build-..." targets
- enable a debug build by default, to simplify development
- bump vendor/DOtherSide
- avoid DOtherSide checks for docs/tests-specific tools like Doxygen
- switch to an in-place build for DOtherSide
- silence the DOtherSide build when V=0, make it more verbose with V=1
- don't delete checked out submodules in the "clean" target
- update build instructions in the README
- centralise Nim compiler options in a top-level "config.nims" (except
  `-d:debug` which needs to be on the command line)
2020-06-08 13:07:25 -04:00
Iuri Matias 1a160cf664 Revert "build system refactoring"
This reverts commit 2449a12fb7.
2020-06-04 17:22:39 -04:00
Ștefan Talpalaru 2449a12fb7 build system refactoring
- unify the "build-..." targets
- enable a debug build by default, to simplify development
- bump vendor/DOtherSide
- avoid DOtherSide checks for docs/tests-specific tools like Doxygen
- switch to an in-place build for DOtherSide
- silence the DOtherSide build when V=0, make it more verbose with V=1
- don't delete checked out submodules in the "clean" target
- update build instructions in the README
- centralise Nim compiler options in a top-level "config.nims" (except
  `-d:debug` which needs to be on the command line)
2020-06-04 14:16:14 -05:00
Ștefan Talpalaru 3cea8d661b Makefile: don't run the "setup-dev" target in vendor/status-go
That one is too aggressive by trying to install system packages and
seems only relevant for developing status-go itself, not just building
the library like we do here.
2020-05-19 15:01:28 -04:00
Richard Ramos 7149f50778 feat: make run 2020-05-19 11:40:55 -04:00
Michael Bradley, Jr e5adeb60f2 chore: DOtherSide shared lib extension differs by platform
`.so` for Linux, `.dylib` for macOS
2020-05-18 14:50:56 -04:00
Richard Ramos 5710ad8079 ft: AppImage 2020-05-15 18:03:55 -04:00
Richard Ramos ce41388a51 AppImg packaging 2020-05-15 17:18:20 -04:00
Richard Ramos c1d1b60f46 Adding nimbus-build-system 2020-05-15 17:18:20 -04:00
Iuri Matias 18db5dc145 add various methods needed for wallet: get price, balance, convert hex wei to eth 2020-05-13 19:22:18 -04:00
emizzle 4769f578a6 feat: Onboarding carousel
Onboarding carousel completed

Redo folder restructuring

NOTES:
1. nim_status_client binary is output to `./bin/nim_status_client`, so you'll need to update your workflow to run this file. README has been updated to reflect this. Also, if you're running VSCode, instructions for code reload were added.
2. All `ui` files now live in `ui/`
3. All lib files (ie `libstatus`) now live in `lib/`
4. Removed the Qt Creater user project file as this is unique to each user
5. Moved the project file to `ui/`, so just open up the `ui` folder in Qt creator and it should locate the project file
6. `-d:release` removed from compilation as it wasn't needed
7. Broke up main.qml in to the main app and onboarding components, however this should be broken down further into more reusable components
8. Click "Get started" to show chat

Format some files using nimpretty
2020-05-12 18:52:51 -04:00
emizzle f3c2331fc6
chore: README update for macos
- Update README for macos
- Add `nimble install` step to README
- Update makefile for macos build to use `.dylib`
2020-05-07 22:17:25 +10:00
Iuri Matias b8900160f4 add make-osx task 2020-05-06 17:43:20 -04:00