wezterm/wezterm-mux-server/Cargo.toml

[package]
name = "wezterm-mux-server"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
resolver = "2"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
anyhow = "1.0"
async_ossl = { path = "../async_ossl" }
config = { path = "../config" }
env-bootstrap = { path = "../env-bootstrap" }
libc = "0.2"
log = "0.4"
mux = { path = "../mux" }
openssl = "0.10"
portable-pty = { path = "../pty", features = ["serde_support"]}
promise = { path = "../promise" }
structopt = "0.3"
umask = { path = "../umask" }
wezterm-mux-server-impl = { path = "../wezterm-mux-server-impl" }
wezterm-gui-subcommands = { path = "../wezterm-gui-subcommands" }

[target."cfg(windows)".dependencies]
winapi = { version = "0.3", features = [ "winuser" ]}
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00			`[package]`
			`name = "wezterm-mux-server"`
			`version = "0.1.0"`
			`authors = ["Wez Furlong <wez@wezfurlong.org>"]`
			`edition = "2018"`
Raise minimum Rust version to 1.51, de-vendor openssl on unix Rust 1.51 allows addressesing a long-standing TODO which was that we shouldn't need to build a vendored copy of openssl on most sensible unix systems. We do require a vendored copy on macOS and Windows, but due to the way that Cargo's feature resolver worked, it wasn't possible for this requirement to be respected. Rust 1.51 introduces `resolver="2"` which can deal with this feature resolution! https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2 The upshot of this is that building wezterm on real unix systems that are not macos will now link against the system libssl, resulting in both a shorter compile time and less headaches arising from having a slightly different openssl used by wezterm than the rest of the system. cc: @jsgf 2021-03-25 19:34:00 +03:00			`resolver = "2"`
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00
			`# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html`

			`[dependencies]`
			`anyhow = "1.0"`
fixup tls mux sessions This adopts smol more broadly, but not yet completely. 2020-10-05 07:07:40 +03:00			`async_ossl = { path = "../async_ossl" }`
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00			`config = { path = "../config" }`
wezterm: add env bootstrap to mux server, too 2020-10-25 09:29:52 +03:00			`env-bootstrap = { path = "../env-bootstrap" }`
clean up mux server startup kindof a lot going on in this commit, unintentionally: * Need the lua context set to be moved into the config crate otherwise configs cannot be parsed by the server and we end up with the default configs * Make the server use smol for async io * Drop the use of the daemonize crate, which I had forked anyway. Just inline our own tighter daemonize module * Improve daemon spawning synchronization, however, it still needs work for windows to avoid blocking forever where we don't do daemonizing. 2020-10-04 19:39:28 +03:00			`libc = "0.2"`
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00			`log = "0.4"`
			`mux = { path = "../mux" }`
			`openssl = "0.10"`
			`portable-pty = { path = "../pty", features = ["serde_support"]}`
			`promise = { path = "../promise" }`
			`structopt = "0.3"`
			`umask = { path = "../umask" }`
mux: factor out server bits to helper crate 2020-12-30 02:21:46 +03:00			`wezterm-mux-server-impl = { path = "../wezterm-mux-server-impl" }`
add --config name=value CLI options `wezterm`, `wezterm-gui` and `wezterm-mux-server` now all support a new `--config name=value` CLI option that can be specified multiple times to supply config overrides. Since there isn't a simple, direct way to update arbitrary fields of a struct in Rust (there's no runtime reflection), we do this work in lua. The config file returns a config table. Before that is mapped to the Rust Config type, we have a new phase that takes each of the `--config` values and applies it to the config table. For example, you can think of configuration as working like this if wezterm is started as `wezterm --config foo="bar"`: ```lua config = load_config_file(); config.foo = "bar"; return config; ``` The `--config name=value` option is split into `name` and `value` parts. The name part is literally concatenated with `config` in the generated lua code, so the name MUST be valid in that context. The `value` portion is literally inserted verbatim as the rvalue in the assignment. Not quoting or other processing is done, which means that you can (and must!) use the same form that you would use in the config file for the RHS. Strings must be quoted. This allows you to use more complicated expressions on the right hand side, such as: ``` wezterm --config 'font=wezterm.font("Fira Code")' ``` The overrides stick for the lifetime of the process; even if you change the config file and reload, then the value specified by the override will take precedence. refs: https://github.com/wez/wezterm/issues/469 refs: https://github.com/wez/wezterm/issues/499 2021-02-27 21:41:48 +03:00			`wezterm-gui-subcommands = { path = "../wezterm-gui-subcommands" }`
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00
fixup windows build 2020-12-30 03:59:59 +03:00			`[target."cfg(windows)".dependencies]`
			`winapi = { version = "0.3", features = [ "winuser" ]}`