Allow specifying cargo features for Rust programs from moz.build
Categories
(Firefox Build System :: General, enhancement)
Tracking
(firefox149 fixed)
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: jmendez, Assigned: jmendez)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
|
Bug 2014246 - Part 1: Add features to [Host]RustProgram objects and moz.build definitions r?glandium
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
For rust crates that are libraries, there is a mozbuild mechanism for specifying the features to enable in the crate, passing features to the RustLibrary() template. The same approach should also be available for rust programs.
For context: I encountered the need for this when wanting to add code specific to Firefox Enterprise to the crashreporter crate. We want to override the telemetry URL for crash pings. I discovered that there was a mechanism for setting Rust features with a RustLibrary template but crashreporter is instead a RustProgram. Because the code paths are similar, I felt it would be easy/good to add support for RustProgram as well.
Comment 5•29 days ago
|
||
For consistency, I think this is a useful change, but I'm not convinced a features is the right way to handle your original need.
(In reply to Mike Hommey [:glandium] from comment #5)
For consistency, I think this is a useful change, but I'm not convinced a features is the right way to handle your original need.
Can you share more about why features is not a good fit or what you suggest instead?
Comment 7•29 days ago
|
||
Features are on/off, they don't give you the liberty to give arbitrary values. Plus, it seems a url shouldn't be hardcoded in the code or even in the binary in the first place. There are even TODO items in the crashreporter client code to that effect.
I think maybe you are concerned that I am trying to add a hardcoded url. If that is the concern, rest assured my plan is somewhat the opposite.
The feature will be an on/off for "is this the enterprise build", tied to MOZ_ENTERPRISE.
And then if MOZ_ENTERPRISE, I override the hardcoded glean url (in the default config from the crashping crate) with a url that is read from the enterprise distribution.ini file.
You can see my WIP here if you want to see more concretely: https://github.com/mozilla/enterprise-firefox/pull/402/changes
If the concerns are deeper than that, let me know and I can find a better place to have the conversation and pull in someone from the crash reporting team.
Updated•27 days ago
|
Updated•27 days ago
|
Updated•24 days ago
|
Updated•24 days ago
|
Comment 10•22 days ago
|
||
Comment 11•22 days ago
|
||
Backed out for causing python/mozbuild failures
- Backout link
- Push with failures
- Failure Log
- Failure line: python/mozbuild/mozbuild/test/backend/test_recursivemake.py::TestRecursiveMakeBackend::test_host_rust_library_with_features TEST-UNEXPECTED-FAIL
Comment 12•22 days ago
|
||
(In reply to jmendez from comment #8)
I think maybe you are concerned that I am trying to add a hardcoded url. If that is the concern, rest assured my plan is somewhat the opposite.
The feature will be an on/off for "is this the enterprise build", tied to MOZ_ENTERPRISE.
And then if MOZ_ENTERPRISE, I override the hardcoded glean url (in the default config from the crashping crate) with a url that is read from the enterprise distribution.ini file.
This doesn't seem like this needs to be specific to MOZ_ENTERPRISE, although for a generic approach, using distribution.ini might not be where we'd want to go.
Updated•22 days ago
|
Updated•22 days ago
|
Comment 13•22 days ago
|
||
Comment 14•21 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/6baaee992d4e
https://hg.mozilla.org/mozilla-central/rev/70d3eb481ac5
| Assignee | ||
Comment 15•21 days ago
|
||
clearing needinfo after fixing the backout
Description
•