gupax/Cargo.toml
2024-05-09 16:32:26 -04:00

123 lines
3.9 KiB
TOML

[package]
name = "gupax"
version = "1.3.6"
authors = ["hinto-janai <hinto.janai@protonmail.com>"]
description = "GUI for P2Pool+XMRig"
documentation = "https://github.com/hinto-janai/gupax"
edition = "2021"
[profile.release]
panic = "abort"
debug = false
strip = "symbols"
codegen-units = 1
lto = true
[profile.dev]
opt-level = 1
debug = true
strip = "none"
debug-assertions = true
overflow-checks = true
incremental = true
[features]
default = []
distro = []
[dependencies]
anyhow = "1.0.71"
arti-client = { version = "0.9.0", features = ["static"] }
arti-hyper = "0.9.0"
benri = "0.1.12"
bytes = "1.4.0"
dirs = "5.0.1"
#--------------------------------------------------------------------------------
egui = "0.27.2"
egui_extras = { version = "0.27.2", features = ["image"] }
## 2023-12-28: https://github.com/hinto-janai/gupax/issues/68
##
## 2024-03-18: Both `glow` and `wgpu` seem to crash:
## <https://github.com/hinto-janai/gupax/issues/84>
## `wgpu` seems to crash on less computers though so...
eframe = { version = "0.27.2", features = ["wgpu"] }
## 2023-02-06: The below gets fixed by using the [wgpu] backend instead of [glow]
## It also fixes crashes on CPU-based graphics. Only used for Windows.
## Using [wgpu] actually crashes macOS (fixed in 0.20.x though).
## [external/egui/crates/eframe/src/native/run.rs] line 41: [.with_srgb(true)]
## This line causes a [panic!] inside a Windows VM, from a Linux host.
## There are many issue threads and PRs to fix it but for now,
## this is here for convenience sake when I'm testing.
## The only change is [.with_srgb()] is set to [false].
#eframe = { path = "external/egui/crates/eframe" }
#egui = { path = "external/egui/crates/egui" }
#egui_glow = { path = "external/egui/crates/egui_glow"}
#egui_extras = { path = "external/egui/crates/egui_extras", features = ["image"] }
#--------------------------------------------------------------------------------
env_logger = "0.10.0"
figment = { version = "0.10.9", features = ["toml"] }
hyper = "0.14.26"
hyper-tls = "0.5.0"
image = { version = "0.24.6", features = ["png"] }
log = "0.4.18"
num-format = { version = "0.4.4", default-features = false }
once_cell = "1.17.2"
portable-pty = "0.8.1"
rand = "0.8.5"
regex = { version = "1.8.3", default-features = false, features = ["perf"] }
rfd = "0.11.4"
serde = { version = "1.0.163", features = ["rc", "derive"] }
serde_json = "1.0"
sysinfo = { version = "0.29.0", default-features = false }
tls-api = "0.9.0"
tokio = { version = "1.21.2", features = ["rt", "time", "macros", "process"] }
toml = { version = "0.7.4", features = ["preserve_order"] }
tor-rtcompat = "0.9.0"
walkdir = "2.3.3"
zeroize = "1.6.0"
strsim = "0.10.0"
strip-ansi-escapes = "0.2.0"
# Unix dependencies
[target.'cfg(unix)'.dependencies]
tar = "0.4.38"
flate2 = "1.0"
sudo = "0.6.0"
# macOS
[target.'cfg(target_os = "macos")'.dependencies]
# On apple-darwin targets there is an issue with the native and rustls
# tls implementation so this makes it fall back to the openssl variant.
#
# https://gitlab.torproject.org/tpo/core/arti/-/issues/715
tls-api-openssl = "0.9.0"
# `arti-client` with `static` doesn't actually
# statically link OpenSSL on macOS, both x64 + ARM.
# Should probably file a bug report.
openssl = { version = "0.10", features = ["vendored"] }
# We don't even use `xz` in `flate2` but this gets dynamically
# linked as well which causes problems, so statically link it.
lzma-sys = { version = "0.1.20", features = ["static"] }
[target.'cfg(not(target_os = "macos"))'.dependencies]
tls-api-native-tls = "0.9.0"
# Windows dependencies
[target.'cfg(windows)'.dependencies]
zip = "0.6.6"
is_elevated = "0.1.2"
wgpu = { version = "0.19.4", features = ["angle"] }
# For Windows build (icon)
[target.'cfg(windows)'.build-dependencies]
winres = "0.1.12"
static_vcruntime = "2.0"
# For macOS build (cargo-bundle)
[package.metadata.bundle]
name = "Gupax"
identifier = "com.github.hinto-janai.gupax"
icon = ["images/icons/icon@2x.png"]
category = "public.app-category.utilities"