Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Print features of dependency crates in neard --version #11176

Open
jancionear opened this issue Apr 29, 2024 · 1 comment
Open

Print features of dependency crates in neard --version #11176

jancionear opened this issue Apr 29, 2024 · 1 comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@jancionear
Copy link
Contributor

#11166 introduced printing enabled cargo features in the output of ./neard --version.
For example:

$ cargo run -p neard --features statelessnet_protocol,new_epoch_sync -- --version
...
neard (release trunk) (build 1.36.1-489-gdf22f90b9) (rustc 1.77.0) (protocol 85) (db 39)
features: [default, json_rpc, near_epoch_sync_tool, new_epoch_sync, rosetta_rpc, statelessnet_protocol]

It prints the features enabled directly for neard, but it doesn't print the ones enabled for neard's dependencies, e.g nearcore.
It would be nice to print the features of dependencies as well.

Recently we had an issue where nearcore/new_epoch_sync was getting enabled even though neard/new_epoch_sync wasn't enabled at all (zulip thread, pr with fix: #11158).

Printing the features of dependencies would allow us to spot that the feature in nearcore is getting enabled and fix the problem immediately. Without that we had to spend a significant amount of time debugging why neard was behaving in a strange way.

@jancionear jancionear added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 29, 2024
@nagisa
Copy link
Collaborator

nagisa commented May 2, 2024

The only way I can think of would be to have a similar build.rs in all of the interesting crates and have those crates export a function/constant that describes the features it has been built with.

OR

Alternatively we could have one mini-crate that exports just such a constant and then defines all the different features that all the other crates would enable by a feature dependency. We could also appropriate e.g. near-primitives-core or some similar crate for this. And then use themis to ensure that we don't forget to maintain said property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

2 participants