<dirbaio[m]>
s/then the defmt macros break, because they emit code doing `defmt::blahblah/then the defmt macros break, because they emit code doing \`defmt::blahblah`/
<dirbaio[m]>
is there a way to have different Cargo features import different defmt versions, but have them all be named defmt from the crate code's PoV? not defmt_03
drebbe[m] has joined #rust-embedded
<drebbe[m]>
I'm actually curious about this also, I have a crate that needs different package versions based on distro (underlying library version breakage)
<dirbaio[m]>
so, naming Cargo features defmt-03, defmt-04, defmt-1 instead of just defmt
diondokter[m] has joined #rust-embedded
<diondokter[m]>
I guess this needs to be changed in defmt. I think there's a crate for macros that figures out what crate:: would be named for macros, but I've forgotten the name
<diondokter[m]>
Also, I did not emotionally prepare for the face reveal :P
<adamgreig[m]>
I think it's already not testing both std and alloc features
<adamgreig[m]>
I think possibly if you added a new matrix element features with just [] or [""] or something it might mean all the entries in include are added as new jobs?
<dirbaio[m]>
* wtf, why is it this way? it makes no sense
<dirbaio[m]>
if that was true though, why did the 1st feature combination win ('std,tokio-1,futures-03') instead of the last ('std,tokio-1,futures-03,defmt-03')???
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
github actions matrices are so confusing
<dirbaio[m]>
same issue happens with alloc vs std, only one is being tested :V
<dirbaio[m]>
and no one noticed lol
<adamgreig[m]>
it's designed to support the use-case of "expand matrix, but add a few extra elements to some of those matrix jobs", I think
<adamgreig[m]>
moreso than "expand matrix, then add some more jobs to the list"
<dirbaio[m]>
they could've added a non-confusing field that does the 1st, then another non-confusing field that does the 2nd 🤪
<adamgreig[m]>
instead they chose violence, lol
<dirbaio[m]>
instead of a single "omg look how smart I am, with these ununderstandable rules, you can do both with a single field 🤓"
<adamgreig[m]>
also it does of course add new entries if the keys you specified aren't all an existing matrix job
<dirbaio[m]>
s/a single//
<adamgreig[m]>
<dirbaio[m]> "if that was true though, why did..." <- once the first combination had been applied, maybe the second no longer matched it 💀
<dirbaio[m]>
but then it'd have added a new combination?
<adamgreig[m]>
I dunno though, naively you'd think that might make it add it as a new entry
<dirbaio[m]>
but it didn't
<adamgreig[m]>
but obviously not
<dirbaio[m]>
¯\_(ツ)_/¯
<dirbaio[m]>
<adamgreig[m]> "I think possibly if you added..." <- yep, this worked :D thanks for the trick
<dirbaio[m]>
e-h has 16 checks now
<adamgreig[m]>
More of a lucky guess than a trick
<dirbaio[m]>
I wonder if testing for thumbv6 and thumbv7 is worth it, or could we just do only one of them
<adamgreig[m]>
For e-h it seems overkill maybe?
<dirbaio[m]>
yea, there's nothing depending on the arch :P
<adamgreig[m]>
Like it should work on arbitrarily many platforms and doesn't have platform specific code so
<dirbaio[m]>
just x86 would be enough
<adamgreig[m]>
Yea...
<dirbaio[m]>
* be enough even
<adamgreig[m]>
Could leave tv6 just in case maybe but not sure why
IlPalazzo-ojiisa has quit [Remote host closed the connection]