Closed artokin closed 9 years ago
Shouldn't this stay? We can have another target that derives from frdm-k64f-gcc. The sockets module needs to be able to use meshing as a socket implementation on platforms where that's possible.
This needs to be removed to solve issue #14. mbed-mesh-api will be included directly by applications who needs it.
@bremoran does that work?
@autopulated I think it has to, otherwise, plain sockets applications will pick up lwm2m, coap, etc.
@bremoran I was assuming we would have a separate target for K64F+mesh shield
@autopulated the point is:
┗─ mbed-mesh-api 0.0.2
┣─ mbed-6lowpan 0.0.13 yotta_modules/mbed-6lowpan
┃ ┣─ mbed-client-c 0.1.6 yotta_modules/mbed-client-c
┃ ┣─ coap-service 0.0.6 yotta_modules/coap-service
┃ ┣─ mbed-6lowpan-eventloop 0.0.11 yotta_modules/mbed-6lowpan-eventloop
┃ ┃ ┗─ mbed-6lowpan-eventloop-adaptor 0.0.14 yotta_modules/mbed-6lowpan-eventloop-adaptor
┃ ┣─ mbed-client-randlib 0.0.2 yotta_modules/mbed-client-randlib
┃ ┣─ libx509-v3 0.0.2 yotta_modules/libx509-v3
┃ ┗─ mbed-client-ecc 0.0.2 yotta_modules/mbed-client-ecc
┣─ mbed-6lowpan-adaptor 0.1.0 yotta_modules/mbed-6lowpan-adaptor
┃ ┗─ mbed-net-sockets 0.1.3 yotta_modules/mbed-net-sockets
┃ ┗─ mbed 3.1.0 yotta_modules/mbed
┗─ mbed-client-libservice 3.0.1 yotta_modules/mbed-client-libservice
There are a lot of dependencies which are not needed for meshing support.
I'm fine with having all the dependencies required to support a mesh sitting below the SAL, but mbed-client, coap-service, mbed-client-randlib, etc., don't belong there.
@artokin, I want to be clear: I don't mind having mbed-mesh-api as a target dependency of the SAL. My concern is that mbed-mesh-api has many dependencies which don't seem to be necessary for implementing the mesh API, such as mbed-client-c, coap-service, mbed-client-randlib, etc.
mbed-mesh-api removed because of issue: https://github.com/ARMmbed/mbed-net-socket-abstract/issues/14
@bremoran would you please review the change?