Explore how private dependencies with links = affect esp-hal

[MabezDev]

I'm slightly concerned that when we release 1.0 some of our deps may in inadvertently break esp-hal builds by accident. I'm not sure what happens when:

• [email protected] with [email protected]
• [email protected] with [email protected] - I think this is breaking change because two different compatible versions of esp-hal could exists in the crate graph, but they would pull in two separate esp-riscv-rt's

Another similar scenario:

• [email protected] with [email protected]
• [email protected] with [email protected] - I don't think this would be a breaking change, but I'm not sure

I'm bringing this up now as although the rt crates are private, they might have the power to break builds if we're not careful, so we need to be sure.

[bjoernQ]

Not sure I understand the concern correctly.

At least for the rt crates I guess nothing but the HALs should depend on them (just checked for whatever reason for riscv-rt (not esp-riscv-rt) there are some PACs and other random crates depending on them) - at least I have no idea why other crates might want to depend on them.

Another thing is having multiple versions of a PAC (or different PACs) in the dependency tree:

For different versions:

warning: Linking globals named '__EXTERNAL_INTERRUPTS': symbol multiply defined!

error: failed to load bitcode of module "esp32c6-099ea990cfb03038.esp32c6.4e03e79070bad390-cgu.0.rcgu.o":

warning: `examples` (bin "gpio_interrupt") generated 1 warning

For different PACs (well - who would do that?)

warning: Linking globals named 'DEVICE_PERIPHERALS': symbol multiply defined!

error: failed to load bitcode of module "esp32s3-c2aab2c2b43b913e.esp32s3.86eeb19eb3c7df55-cgu.0.rcgu.o":

I also tried to check which of our external dependencies (of esp-hal) includes links and doesn't seem like any of them does (esp-hal-embassy is a different thing)

Our own crates:
xtensa-lx - why? xtensa-lx-rt doesn't .... I'd expect the rt to contain it not the arch-support crate
esp-println - makes sense to not have multiple versions in parallel, usually only the binary crate would include it but esp-backtrace includes a dependency (since it needs to)
esp-hal - makes sense - there should be only one HAL but that also means users can only have one version of it in the dep-tree anyways

esp-riscv-rt currently doesn't include a links key (but risv-rt does)

[jessebraham]

I'm also not sure I understand the concern here. The HAL depends on these packages, not user code. We are in control of these dependencies, as long as we follow semver with our releases I don't think there should be any issues?