fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
nohit has quit [Ping timeout: 245 seconds]
nohit has joined #rust-embedded
nohit has quit [Read error: Connection reset by peer]
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
nohit has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
jackneill has quit [Ping timeout: 250 seconds]
jackneill has joined #rust-embedded
jackneilll has joined #rust-embedded
GenTooMan has quit [Read error: No route to host]
jackneill has quit [Ping timeout: 268 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 268 seconds]
PyroPeter has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
unmanbearpig has quit [*.net *.split]
troth has quit [*.net *.split]
unmanbearpig has joined #rust-embedded
troth has joined #rust-embedded
unmanbearpig has quit [Max SendQ exceeded]
unmanbearpig has joined #rust-embedded
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@thejpster:matrix.org> How do we feel about default features vs negative features?
<re_irc> <@thejpster:matrix.org> I have a crate for a chip, and there's some feature that is generally useful for people, but some people might want to do their own thing.
<re_irc> <@thejpster:matrix.org> (specifically, including a default memory.x file in the BSP, as the particular board you have defines the flash-chip size).
<re_irc> <@thejpster:matrix.org> I recall people don't like "negative features", as in:
<re_irc> <@thejpster:matrix.org> ```toml
<re_irc> <@thejpster:matrix.org> rp_hal = { version = "1.0", features=["no_memory_file"] }
<re_irc> <@thejpster:matrix.org> The alternative is:
<re_irc> <@thejpster:matrix.org> Oh, also the issue is that I can't have both the HAL and the BSP copy over a memory.x file, as I don't think the linker order is well defined. But the HAL needs one otherwise the examples don't build.
<re_irc> <@dirbaio:matrix.org> negative features are bad, because crate A might enable the negative feature, which breaks crate B which wants to use the feature
<re_irc> <@dirbaio:matrix.org> which can't happen with positive features, each crate enables what it needs
<re_irc> <@thejpster:matrix.org> The feature in this case is "don't copy memory.x out ${OUT_DIR} because another crate in the tree is going to do it"
<re_irc> <@dirbaio:matrix.org> for memory.x it *might* be fine because it doesn't really remove stuff from the Rust API
<re_irc> <@thejpster:matrix.org> I think my negative feature is actually a positive feature
<re_irc> <@dirbaio:matrix.org> `custom-memory-x`
<re_irc> <@dirbaio:matrix.org> haha
<re_irc> <@dirbaio:matrix.org> it's positive now!
<re_irc> <@thejpster:matrix.org> Nice
<re_irc> <@dirbaio:matrix.org> I'd just make it `memory-x` and *not* enable it by default
<re_irc> <@dirbaio:matrix.org> and have the quickstart/template/examples enable it
<re_irc> <@dirbaio:matrix.org> everyone starts their projects copying from some quickstart
<re_irc> <@dirbaio:matrix.org> having it enabled by default doesn't gain you much usabiliy
<re_irc> <@thejpster:matrix.org> But how does an in-tree example enable a feature?
<re_irc> <@thejpster:matrix.org> Also, can build.rs see the features enabled? I know if can set more features.
<re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: uhhhh
<re_irc> <@thejpster:matrix.org> `cargo build --examples` must not fail.
<re_irc> <@dirbaio:matrix.org> an example can do
<re_irc> <@dirbaio:matrix.org> [[example]]
<re_irc> <@dirbaio:matrix.org> ```toml
<re_irc> <@dirbaio:matrix.org> required-features = ["std", "phy-raw_socket", "proto-ipv4"]
<re_irc> <@dirbaio:matrix.org> name = "tcpdump"
<re_irc> <@dirbaio:matrix.org> but I think the example doesn't get built if the features are not enabled
<re_irc> <@dirbaio:matrix.org> like, `cargo build --examples` won't build it, and `cargo build --example foo` will complain and tell you to add `--features`
<re_irc> <@dirbaio:matrix.org> IMO in-crate examples don't work for embedded
<re_irc> <@dirbaio:matrix.org> I just do in-tree examples but in a separate crate, like [this](https://github.com/embassy-rs/embassy/tree/master/examples/nrf)
<re_irc> <@dirbaio:matrix.org> which is nice because the file structure is now identical to what an end-user crate would do
<re_irc> <@adamgreig:matrix.org> I've not tried it but can you depend on yourself and add features in dev-dependencies for building examples?
<re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: `CARGO_FEATURE_FOO` envvar, [docs](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts)
<re_irc> <@adamgreig:matrix.org> Separate examples crate that doubles as a template is nice too of course
<re_irc> <@dirbaio:matrix.org> adamgreig: that seems very cursed, I don't think it works
<re_irc> <@adamgreig:matrix.org> dev-deps are definitely included for examples and features are unified but yea idk if it's just too cursed
<re_irc> <@dirbaio:matrix.org> yeah but the "current crate" is included as kind-of a dev-dep automatically so... :S
<re_irc> <@adamgreig:matrix.org> Yea...
<re_irc> <@thejpster:matrix.org> OK, I can see that --features=custom-memory-x sets ${CARGO_FEATURE_CUSTOM_MEMORY_X}
<re_irc> <@thejpster:matrix.org> Throwing out all the in-tree examples I guess isn't impossible. It's a shame though.
<re_irc> <@dirbaio:matrix.org> they can still be in-tree, you can have multiple crates in the same git repo
<re_irc> <@thejpster:matrix.org> OK, yes, that's fair.
<re_irc> <@dirbaio:matrix.org> i'd make the feature `memory-x` and not make it enabled by default
<re_irc> <@dirbaio:matrix.org> embassy-stm32 does that
<re_irc> <@dirbaio:matrix.org> not enabling by default avoids some random crate accidentally enabling it by forgetting to add `default-features=false`
<re_irc> <@dirbaio:matrix.org> have it enabled it in the examples/quickstart and have people copypaste from there
<re_irc> <@thejpster:matrix.org> But that means moving the examples somewhere that can set the flag
<re_irc> <@dirbaio:matrix.org> yeah
<re_irc> <@dirbaio:matrix.org> you'll run into lots of other cursed stuff with in-crate examples anyway
<re_irc> <@thejpster:matrix.org> such as?
<re_irc> <@dirbaio:matrix.org> you can't have a build.rs that applies just to the example bins
<re_irc> <@dirbaio:matrix.org> hm, which is a problem if you want build.rs to drop the memory.x as you would if you didn't have the `memory-x` feature heh
<re_irc> <@dirbaio:matrix.org> same for `.cargo/config.toml`
<re_irc> <@dirbaio:matrix.org> and also Cargo feature management is cursed as discussed above
fabic has quit [Ping timeout: 265 seconds]
fabic has joined #rust-embedded
<re_irc> <@barafael:matrix.org> I've run into issues with in-repo examples before. I'm sure it's partly just a hard problem, but it seems very un-rustic that they are such a hassle
xnor has quit [Ping timeout: 245 seconds]
xnor has joined #rust-embedded
xnor has quit [Changing host]
xnor has joined #rust-embedded
xnor has quit [Quit: Changing server]
xnor has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc> <@thejpster:matrix.org> This might be more generally applicable, so I'll cross-post it here - I've started work on a crate to support "Binary Info", as supported by Raspberry Pi's `picotool` program.
<re_irc> <@thejpster:matrix.org> https://github.com/rp-rs/rp-binary-info
<re_irc> <@thejpster:matrix.org> Might be useful for stuffing version numbers and things into your binaries in a way a tool can easily pull them out of the ELF file.
fabic has quit [Ping timeout: 246 seconds]