CMake: Fix mbed-802.15.4-rf driver #14546
Conversation
ciarmcom
added
the
release-type: patch
|
@rwalton-arm, thank you for your changes. |
mbed-nanostack should depend on mbed-802.15.4-rf to avoid a linker error with an undefined reference to `NanostackRfPhy::get_default_instance()`. The error occurs when `device_has: 802_15_4_PHY` is defined and the consumer depends on mbed-nanostack in their CMakeLists.txt. Previously we linked mbed-nanostack to mbed-802.15.4-rf, so mbed-802.15.4-rf's usage requirements weren't forwarded to consumers who depended on mbed-nanostack. With the previous configuration, the consumer would have to depend on mbed-802.15.4-rf directly to avoid an issue. This seems like a layering violation: it appears that mbed-nanostack is "the API" and mbed-802.15.4-rf is one of several possible implementations which are selected based on configuration macros. This commit changes the flow of dependencies so that mbed-nanostack ends up with the correct symbol definitions.
rwalton-arm
force-pushed
the
dev/rwalton-arm/fix-connectivity-driver
branch
from
c4f9897
to
c7c2580
Compare
|
We should link a driver to nanostack but aren't we still missing something here? As it is, atmel is a default driver always present. If a user uses another there would be duplicated drivers in the tree (I checked, all folders under this directory define the same functionality). I assume atmel should be conditional as well - depends on I dont know how other drivers (mcr for instance) were selected with cli1 as they are not "components" neither using any label in directory name ? I might be missing something. |
|
|
CI started |
Jenkins CI Test : ❌ FAILEDBuild Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
|
CI started |
Jenkins CI Test : ✔️ SUCCESSBuild Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
mbedmain
removed
release-type: patch
Summary of changes
mbed-nanostack should depend on mbed-802.15.4-rf to avoid a linker error
with an undefined reference to
NanostackRfPhy::get_default_instance().The error occurs when
device_has: 802_15_4_PHYis defined and theconsumer depends on mbed-nanostack in their CMakeLists.txt. Previously
we linked mbed-nanostack to mbed-802.15.4-rf, so mbed-802.15.4-rf's
usage requirements weren't forwarded to consumers who depended on
mbed-nanostack.
With the previous configuration, the consumer would have to depend on
mbed-802.15.4-rf directly to avoid an issue. This seems like a layering
violation: it appears that mbed-nanostack is "the API" and
mbed-802.15.4-rf is one of several possible implementations which are
selected based on configuration macros.
This commit changes the flow of dependencies so that mbed-nanostack ends
up with the correct symbol definitions.
Impact of changes
Migration actions required
Documentation
None
Pull request type
Test results
Reviewers