platform: fix internal platform headers

[0xc0170]

Summary of changes

Note: I am using platform as a component with CMake, therefore include paths are set differently than with our build system (CMake is not including everything thus this is failing).

If we take platform as a component, platform/source would be outside of this component. I moved internal headers into internal folder.

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[x] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[ciarmcom]

@0xc0170, thank you for your changes.
@ARMmbed/mbed-os-core @ARMmbed/mbed-os-maintainers please review.

[LDong-Arm]

@0xc0170 Removing the prefix is the right thing to do - the library folder name is "unknown" to the code itself. 👍

I would rather move these to include, they are not source are they?

They are non-API internal headers, and the idea is to have them source. I guess in CMake we can define those headers to be private to "this" module?

If they are they should be moved then under source/platform/ rather to provide path as request or?

The reason we have include/platform/... is to expose include so users can do "namespaced" #include platform/.... But source and private headers are local to this module, so the namespace shouldn't be needed. It would be too cumbersome if all internal includes need the namespace despite being in the same library in my opinion.

But please let us know if the above assumption doesn't actually work easily with CMake.

[0xc0170]

I found more offenders and even outside of platform component, I updated the above comment.. But will add it as well here:

Another error is (I haven't yet fixed it here as it is outside of platform component):

../mbed-os/events/source/equeue_mbed.cpp:41:10: fatal error: platform/source/mbed_os_timer.h: No such file or directory
  41 | #include "platform/source/mbed_os_timer.h"

Also mbed-os/rtos/source/Kernel.cpp and possibly other files, I'll find all once we agree how these should be done.

Events, rtos uses internal source files. The question now is - is t his really internal header , shouldn't it be moved to include/ folder and that would actually fix the issue I am seeing ?

[kjbracey]

That header is not supposed to be public API, but at some point equeue_mbed.cpp found itself needing to use some of the mbed::internal stuff inside them to work around a bug. Something of a hack.

Given that everything in the header I didn't want people to use in apps is namespaced as mbed::internal, it's notionally safe to expose pull if out of source and onto standard header path to permit the cross-call. Might need some extra "internal" Doxygen group marking, and maybe add an "internal/" onto the path if that's your current style.

[LDong-Arm]

Agree with @kjbracey-arm, moving mbed_os_timer.h to include/platform/internal/ complies with the new directory structure. (Well, #include platform/internal/mbed_os_timer.h would be doable by anyone due to how -I behaves, but "internal" is a good enough warning to users in my opinion.)

[0xc0170]

I moved 3 headers into internal "namespace" as mentioned above. Please review

[0xc0170]

I've missed few more spots, updated

[0xc0170]

CI started

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-ARM	✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage	✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest	✔️

[0xc0170]

Travis restarted (this still needs reviews)

[0xc0170]

ready for reviews again

[rajkan01]

LGTM