status-im
/
status-desktop
mirror of https://github.com/status-im/status-desktop.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
status-desktop/config.nims

66 lines
2.6 KiB
Plaintext
Raw Normal View History

build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
if defined(release):
switch("nimcache", "nimcache/release/$projectName")
else:
switch("nimcache", "nimcache/debug/$projectName")
--threads:on
--opt:speed # -O3
--debugger:native # passes "-g" to the C compiler
--define:ssl # needed by the stdlib to enable SSL procedures
if defined(macosx):
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
--dynlibOverrideAll # don't use dlopen()
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
--tlsEmulation:off
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
switch("passL", "-lstdc++")
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
# DYLD_LIBRARY_PATH doesn't always work when running/packaging so set rpath
# note: macdeployqt rewrites rpath appropriately when building the .app bundle
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
switch("passL", "-rpath" & " " & getEnv("QT5_LIBDIR"))
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
switch("passL", "-rpath" & " " & getEnv("STATUSGO_LIBDIR"))
feat(@desktop/keycard): initial keycard implementation Keycard implementation affected onboarding/login flows. - new user - first run - new keys into keycard - new user - first run - import seed phrase into keycard - old user - first run - login importing from keycard - login the app using keycard Fixes: #5972
2022-07-21 11:29:18 +00:00
switch("passL", "-rpath" & " " & getEnv("STATUSKEYCARDGO_LIBDIR"))
build: dynamically link to status-go built as a shared library
2020-08-06 21:14:06 +00:00
# statically link these libs
fix: on macOS download openssl@1.1 bottle because openssl bottle is now alias for openssl@3
2021-09-24 16:12:47 +00:00
switch("passL", "bottles/openssl@1.1/lib/libcrypto.a")
switch("passL", "bottles/openssl@1.1/lib/libssl.a")
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
switch("passL", "bottles/pcre/lib/libpcre.a")
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
# https://code.videolan.org/videolan/VLCKit/-/issues/232
switch("passL", "-Wl,-no_compact_unwind")
chore: fix nim build warnings (#12796) * chore: turn off 'generic methods are deprecated' warnings * chore: fix homebrew bottles version and macos-min-version * chore: suppress dotherside deprecation warnings * chore: fix more nim unused import warnings * chore(qt.nim): explicit cstring conversion to fix warning * chore: fix all baseless methods
2023-11-20 16:04:11 +00:00
# set the minimum supported macOS version to 11.0
switch("passC", "-mmacosx-version-min=11.0")
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
elif defined(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
--app:gui
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
--tlsEmulation:off
switch("passL", "-Wl,-as-needed")
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
else:
build: enhance build system so that it can run directly on Windows Replaces #82, which in any case is out-of-date re: the current state of this repo's Makefile. Introduces the ability to build `nim_status_client.exe` directly on Windows, i.e. without needing to use Windows Subsystem for Linux or otherwise cross-compile on Linux. Note: this commit does not introduce packaging or code signing for the Windows build as those pieces are still a work in progress. The `make` targets should be run in a Bash shell, e.g. in *Git Bash* as included in the installation of [Git for Windows][git-win]. [Microsoft Visual C++ Build Tools][ms-build] must be installed. Qt's `MSVC 2017 64-bit` and `MinGW 7.3.0 64-bit` toolchains must both be installed, e.g. with the Qt Online Installer tool. CMake needs to be installed; it is available via the Qt Online Installer tool under *Developer and Designer Tools* (`CMake 3.17.1 64-bit`). A couple of additional tools need to be installed (e.g. with [scoop][scoop]) and availble in `PATH`: * findutils * go For `.dll` resolution to function as needed, in a Bash shell `PATH` should be modified like this (might be different depending on how/where things were installed): ```bash export QTBASE="/c/Qt" export QTDIR="${QTBASE}/5.14.2/msvc2017_64" export PATH="${HOME}/scoop/shims:${PATH}" export PATH="${QTDIR}/bin:${PATH}" export PATH="${QTBASE}/Tools/mingw730_64/bin:${PATH}" export PATH="${QTBASE}/Tools/CMake_64/bin:${PATH}" ``` With those modifications in place, to build `nim_status_client.exe` do: ``` mingw32-make.exe V=1 ``` To run the executable do: ``` mingw32-make.exe run ``` [git-win]: https://gitforwindows.org/ [ms-build]: https://visualstudio.microsoft.com/visual-cpp-build-tools/ [scoop]: https://scoop.sh/
2020-07-08 16:48:13 +00:00
--dynlibOverrideAll # don't use dlopen()
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
# dynamically link these libs, since we're opting out of dlopen()
fix: use libssl 1.1
2024-05-23 22:20:07 +00:00
switch("passL", "-l:libcrypto.so.1.1")
switch("passL", "-l:libssl.so.1.1")
chore: refactor Linux and macOS build/packaging steps Replaces PR #105. Implement a `pkg-macos` target that ultimately results in `Status.dmg` being written to `pkg/`. Due to [limitations][limits] of the OpenSSL `.dylib`s in `/usr/lib/` on macOS, `libssl.a` and `libcrypto.a` are statically linked into `bin/nim_status_client` from a [Homebrew][brew] "bottle" that is compatible with macOS 10.13 (the oldest macOS version compatible with Qt v5.14). `pkg-macos` creates an `.app` bundle layout in `tmp/macos/dist` based partly on information in a very helpful [StackOverflow answer][so-answer]. Note the part of the answer (toward the end) that explains a problem with the working directory and how to fix it. That's the reason for the `nim_status_client.sh` script introduced in this commit (it gets copied into the bundle). It's also the reason for having `Info.plist` copied into the bundle before `macdeployqt` is run (see below) and then overwriting it with `Info.runner.plist` before creating the `.dmg` file. The app icons file `status-icon.icns` was taken from `deployment/macos/` in the [status-react][sr] repo. The [`macdeployqt`][macdeployqt] tool is used to copy the needed portions of Qt into the bundle; it automatically updates `rpath`, etc. so the `nim_status_client` executable in the bundle can locate the libs within the bundle. `macdeployqt` is run twice, for the "outer" and "inner" `.app` bundles, because of an apparent bug in `macdeployqt` that results in QtWebEngine related resources not being processed correctly on the first pass. This results in some bloat in the final bundle but it seems unavoidable at present. The [create-dmg][cdmg] tool is used to package the bundle into a `.dmg` file. There are two reasons for this: 1. It produces a nice looking icon for the `.dmg` that overlays the Status logo on an external disk icon. 2. `Info.plist` needs to be overwritten after running `macdeployqt` (see explanation above) but before creating the `.dmg` file. If we passed the `-dmg` cli option to `macdeployqt` to have it generate the `.dmg` file then it wouldn't be possible to overwrite `Info.plist`. So there is a cosmetic reason and a practical reason for using another tool. Probably the biggest downside is that `create-dmg` is implemented in Node.js so it needs to be installed with `npm`; that's the reason this commit introduces `package.json`, etc. Note that zero code from `node_modules` ends up in the `.app` bundle or the `.dmg` file. Code signing of the macOS `.app` bundle and `.dmg` is attempted if the environment variable `MACOS_CODESIGN_IDENT` is defined. In that case, the environment variable `MACOS_KEYCHAIN_OPT` may optionally be defined with the path to a preferred keychain database file. Refactor a number of sections in the Makefile for consistency's sake, e.g. the `appimage` target becomes `pkg-linux` and ultimately results in `NimStatusClient-x86_64.AppImage` being written to `pkg/`. Make a number of changes to bring the Linux packaging steps up-to-date and use the `-qmlimport` cli option of `linuxdeployqt` to simplify resolution of Qt plugins. Note that `make pkg` will correctly resolve to `make pkg-linux` or `make pkg-macos` depending on the OS in use. Consistently use lower-case "c" in the name of *components* directories and imports. [limits]: https://developer.apple.com/forums/thread/124782 [brew]: https://brew.sh/ [so-answer]: https://stackoverflow.com/a/3251285 [sr]: https://github.com/status-im/status-react/tree/develop/deployment/macos [macdeployqt]: https://doc.qt.io/qt-5/macos-deployment.html [cdmg]: https://github.com/sindresorhus/create-dmg
2020-06-04 20:56:44 +00:00
# don't link libraries we're not actually using
switch("passL", "-Wl,-as-needed")
build system refactoring - unify the "build-..." targets - enable a debug build by default, to simplify development - bump vendor/DOtherSide - avoid DOtherSide checks for docs/tests-specific tools like Doxygen - switch to an in-place build for DOtherSide - silence the DOtherSide build when V=0, make it more verbose with V=1 - don't delete checked out submodules in the "clean" target - update build instructions in the README - centralise Nim compiler options in a top-level "config.nims" (except `-d:debug` which needs to be on the command line)
2020-05-25 02:18:37 +00:00
--define:chronicles_line_numbers # useful when debugging
remove vendor/nim-nat-traversal and fix/hide some warnings
2020-06-23 00:50:51 +00:00
# The compiler doth protest too much, methinks, about all these cases where it can't
# do its (N)RVO pass: https://github.com/nim-lang/RFCs/issues/230
switch("warning", "ObservableStores:off")
# Too many false positives for "Warning: method has lock level <unknown>, but another method has 0 [LockLevel]"
switch("warning", "LockLevel:off")
Nim 1.6 Upgrade Nim compiler to 1.6. The necessary changes are related to how `for` loops now implicitly create a `lent` type, which is Nim's way of creating a "temporary" reference to an item inside a collection - this helps performance by avoiding a copy of the data, but it also means that the copy that previously was implicit in the for loop must be made explicit in the code.
2023-03-15 09:03:30 +00:00
# No clean workaround for this warning in certain cases, waiting for better upstream support
switch("warning", "BareExcept:off")
chore: force some warnings as errors (#14068)
2024-03-20 20:08:43 +00:00
# We assume this as a good practive to keep `else` even if all cases are covered
switch("warning", "UnreachableElse:off")
# Those are popular to miss in our app, and quickly make build log unreadable, so we want to prevent them
switch("warningAsError", "UseBase:on")
switch("warningAsError", "UnusedImport:on")
chore: fill holes in ChatType enum (#14257) * chore: fill holes in ChatType enum * chore: fix Spacing warning
2024-04-03 13:47:41 +00:00
switch("warningAsError", "Deprecated:on")
switch("warningAsError", "HoleEnumConv:on")
chore: force some warnings as errors (#14068)
2024-03-20 20:08:43 +00:00
# Workaround for https://github.com/nim-lang/Nim/issues/23429
switch("warning", "UseBase:on")
switch("warning", "UnusedImport:on")
chore: fill holes in ChatType enum (#14257) * chore: fill holes in ChatType enum * chore: fix Spacing warning
2024-04-03 13:47:41 +00:00
switch("warning", "Deprecated:on")
switch("warning", "HoleEnumConv:on")