Remove mbed_trace dependency to Nanomesh headers

[SeppoTakalo]

Description

This library only uses standard types from C99, and
thus does not need compiler specific tweaks from ns_types.h

Reason for dropping the Nanomesh header from mbed-trace, is that it now allows applications to use tracing library in BareMetal builds without dependency to Nanomesh.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@kjbracey-arm

Release Notes

[kjbracey]

My recollection is that the ns_types.h was to overcome some compiler glitches in stdint etc on some platforms (and maybe silence some compiler warnings?). Not sure if it's still needed.

Probably can be removed here. ns_trace.h compatibility glue could maybe add it, so ns_trace.h includes ns_types.h then mbed_trace.h?

[0xc0170]

Probably can be removed here. ns_trace.h compatibility glue could maybe add it, so ns_trace.h includes ns_types.h then mbed_trace.h?

@SeppoTakalo What do you think?

[SeppoTakalo]

I'm not sure there is anything in particular that the tracing library itself depends on from ns_types.h

To my understanding, the header itself only uses standard types uint8_t etc.. Users of this library might use PRIx32 and those macros, but should they rely on mbed-trace.h to include those? not sure.. I added the <inttypes.h> here anyway.

I would like to push this as is, as we would like to use this in bare metal builds. Its a bit annoying to require: ['nanomesh'] when all we need is standard headers.

[SeppoTakalo]

The littlefs tests seemed to fail, because this is not in: https://github.com/ARMmbed/mbed-os/pull/11419/files

Not sure why, but they seems to somehow include mbed-trace.h, and as a consequence they include <inttypes.h> as well.

[kjbracey]

Users of this library might use PRIx32 and those macros, but should they rely on mbed-trace.h to include those?

The issue was more subtle, as I recall - including stdint.h "bare" could mess up later users - eg not defining __STDC_LIMIT_MACROS before doing it. We were trying to centralise those headers into one include that made sure they were always included in a controlled way on first include from a Nanostack source file.

IIRC, all nanostack files include "ns_trace.h" rather than "mbed_trace.h", so if that is modified to include "ns_types.h" first before including "mbed_trace.h", then this change should be 100% solid from Nanostack's PoV.

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

[0xc0170]

IIRC, all nanostack files include "ns_trace.h" rather than "mbed_trace.h", so if that is modified to include "ns_types.h" first before including "mbed_trace.h", then this change should be 100% solid from Nanostack's PoV.

@SeppoTakalo this PR needs na update or is it good as it is (nanostack is being updated in separate PR and does not have anything related to this PR, correct?)

[kjbracey]

This incorporates my requested change to Nanostacklibservice. Shouldn't conflict with the incoming Nanostack PR, assuming they're not touching this file. Change can be backported to libservice main repo via standard subtree synch mechanism in future.

[SeppoTakalo]

@0xc0170 this is now good to go.

Not a high priority, but if this still can, I would prefer to have it already in RC2 or RC3, however, if not possible, the next patch release is acceptable as well.

[0xc0170]

CI started

[adbridge]

@0xc0170 this is now good to go.

Not a high priority, but if this still can, I would prefer to have it already in RC2 or RC3, however, if not possible, the next patch release is acceptable as well.

Follow on RCs should really only be used for blocking / critical fixes. As this appears to be neither and we already have 'too' many things going to RC2, I think this needs to go to 5.14.1.

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts