Commit Graph

80 Commits

Author SHA1 Message Date
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
Richard Ramos 9a93298508
feat: makefile 2020-05-06 17:26:32 -04:00