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
Only 2 dependencies left:
* Testing only: OHHTTPStubs for network mocking
* GzipSwift: for TestUtils to decode gzip'ed payloads
Both are available as Swift packages, so we can consume them that way.
The Glean C# SDK had been abandoned for quite some time
and officially been marked deprecated in September (9836b2063d).
This just sunsets it officially by removing the codebase from the repository.
This reverts commit ed4c58a6d6.
As long as we ship a carthage archive we need that hack, otherwise it
will try to build for both simulator and hardware ARM, failing to merge them
together.
This additionally adds a note on the bash version
to keep the files in sync.
It's much easier to test content on Windows by doing
`mdbook serve docs/user` FWIW.
Previously it used whatever was the latest version.
This could lead to CI failures when we update glean_parser but don't
update inside this repository.
[doc only]
The spellchecking CI *does* highlight the misspelled word using colorizing when
run locally, but this is somehow broken when displayed in the CircleCI log
viewer online.
There doesn't appear to be a way to put custom delimiters around the misspelled
word, but it is possible to *only* display the misspelled word without the
context from the rest of the line. This is probably more helpful to understand
which words the spellchecker doesn't like.
Running the spellchecker locally through `make spellcheck` doesn't change --
that will still use the interactive version of aspell.
Carthage in default configuration breaks compilation in Xcode 12,
as it tries to build for the simulator now for the arm64 target as well.
That target however is for Apple Silicion, the upcoming Arm platform.
We don't need to run simulator builds there yet (we don't even have
those devices!), so we can safely ignore it.
We need to teach both Carthage about it and for simplification we do the
same for the sample app specifically.
Upstream issue: https://github.com/Carthage/Carthage/issues/3019
Jan-Erik Rediger
brizental
Alessio Placitelli
Beatriz Rizental
Michael Droettboom