glean/Cargo.toml

[workspace]
resolver = "2"

members = [
  "glean-core",
  "glean-core/rlb",
  "glean-core/bundle",
  "glean-core/bundle-android",
  "glean-core/build",
  "samples/rust",
  "tools/embedded-uniffi-bindgen",
]

default-members = [
  "glean-core",
  "tools/embedded-uniffi-bindgen",
]

[profile.release]
opt-level = "s"
debug = false
lto = true
Create initial Rust workspace 2019-03-18 15:03:49 +03:00			`[workspace]`
Address beta warnings 2023-07-12 12:29:21 +03:00			`resolver = "2"`
Create initial Rust workspace 2019-03-18 15:03:49 +03:00
			`members = [`
Fix cargo workspace 2019-03-19 19:01:25 +03:00			`"glean-core",`
Fixup the release script and main Cargo.toml 2020-10-20 12:49:09 +03:00			`"glean-core/rlb",`
Rust: Split glean-ffi up into 2 crates glean-ffi carries all the no_mangle extern "C" definitions of our FFI layer. This is getting included in mozilla-central soon. However we can't have crates that are build as a `cdylib` as dependencies in mozilla-central, as this will then produce said `cdylib` during the build, which breaks at least on one build target. We don't need that `cdylib` published, we only need it for builds we ship ourselves: Kotlin, Swift & Python. Therefore we split this part into a `glean-bundle` crate which itself will generate a `cdylib` by the name `libglean_ffi`. Our builds only need to reference that other workspace member, but don't need to change what library they are loading. Now `glean-ffi` is a plain ol' Rust crate and we can use that in mozilla-central. 2021-04-13 15:39:51 +03:00			`"glean-core/bundle",`
Kotlin: Use the library name `xul` for the core parts This is a hack: Glean is build into libxul from mozilla-central and users consume it as part of GeckoView. Because UniFFI does not have the option to switch the library to consume, except at build time, we use this hack for now. 2022-04-19 17:35:10 +03:00			`"glean-core/bundle-android",`
Implement a glean-build crate for use in Rust consumers This crate should be used as a build dependency in Rust consumers. In their `build.rs` they can call the builder to auto-generate code from `metrics.yaml` and `pings.yaml` definitions: glean_build::Builder::default() .metrics("metrics.yaml") .pings("pings.yaml") .generate() .expect("Error generating Glean Rust bindings"); This requires a working Python3 & pip installation. Windows untested. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1713573 and https://bugzilla.mozilla.org/show_bug.cgi?id=1772566 2022-06-21 12:40:52 +03:00			`"glean-core/build",`
			`"samples/rust",`
Use a tooling crate to run uniffi-bindgen and builtin bindgen in build.rs 2022-05-05 17:15:24 +03:00			`"tools/embedded-uniffi-bindgen",`
Rust: Split glean-ffi up into 2 crates glean-ffi carries all the no_mangle extern "C" definitions of our FFI layer. This is getting included in mozilla-central soon. However we can't have crates that are build as a `cdylib` as dependencies in mozilla-central, as this will then produce said `cdylib` during the build, which breaks at least on one build target. We don't need that `cdylib` published, we only need it for builds we ship ourselves: Kotlin, Swift & Python. Therefore we split this part into a `glean-bundle` crate which itself will generate a `cdylib` by the name `libglean_ffi`. Our builds only need to reference that other workspace member, but don't need to change what library they are loading. Now `glean-ffi` is a plain ol' Rust crate and we can use that in mozilla-central. 2021-04-13 15:39:51 +03:00			`]`

			`default-members = [`
			`"glean-core",`
Use a tooling crate to run uniffi-bindgen and builtin bindgen in build.rs 2022-05-05 17:15:24 +03:00			`"tools/embedded-uniffi-bindgen",`
Create initial Rust workspace 2019-03-18 15:03:49 +03:00			`]`
Reproducable builds by keeping the lock file 2019-03-18 18:32:35 +03:00
			`[profile.release]`
			`opt-level = "s"`
Don't include symbols in release build 2019-10-02 16:28:23 +03:00			`debug = false`
Reproducable builds by keeping the lock file 2019-03-18 18:32:35 +03:00			`lto = true`