Adding build profiles to build_release.py and singletest.py #2877
Conversation
|
@mbed-bot: TEST HOST_OSES=ALL |
|
[Build 1008] |
|
@mbed-bot: TEST HOST_OSES=ALL |
|
/morph test |
|
[Build 1009] |
Result: ABORTEDYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1019 Build Prep failed! |
bridadan
force-pushed
the
build-profiles-release-singletest
branch
from
0cd6ca4 to
9905f5d
Compare
bridadan
force-pushed
the
build-profiles-release-singletest
branch
from
9905f5d to
64d09e1
Compare
|
@theotherjimmy I've added /morph test |
|
@mbed-bot: TEST HOST_OSES=ALL |
|
[Build 1010] |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 1020 All builds and test passed! |
| @@ -22,6 +22,16 @@ | |||
| "cxx": ["--cpp", "--no_rtti", "--no_vla"], | |||
| "ld": [] | |||
| }, | |||
| "uARM": { | |||
There was a problem hiding this comment.
@bridadan @theotherjimmy
Why did we add another "toolchain" in order to use MicroLib instead of having something like this in arm.py?
There was a problem hiding this comment.
@hugueskamba The uARM toolchain was present in Mbed OS 2.0, so it would have been a breaking change to remove it. In Mbed OS 5.0 the default_lib parameter was added to GCC (and maybe IAR as well?). I always hoped we would eventually deprecate the uARM toolchain and use the default_lib in its place!
There was a problem hiding this comment.
Thanks @bridadan,
Wouldn't removing uARM cause other changes? The first thing I see is the fact that the boot code is different. However, would it just be as simple as moving the stuff from mbed_boot_arm_micro.c to mbed_boot_arm_std.c, renaming mbed_boot_arm_std.c to mbed_boot_arm.c and adding a bunch of macros?
There was a problem hiding this comment.
Yup like you said its more complicated than just changing the tools. I think that's one of the main reasons we didn't do it at the time. Changing all the device code would be a big effort that's for sure.
But yeah I think that's the general gist. I have to admit I'm not as familiar with the boot sequence requirements for uARM so I may be missing a few details.
There was a problem hiding this comment.
uARM was one of the first toolchains as I recall, came after ARM.
We added much much later default_lib (when we wanted to use newlib with GCC ARM) and due to wide use of uARM back then (lot of small devices had it) it stayed for backward compatibility. Things changed after we moved to 5, rtos and thread safety.
Description
The build profiles configuration was missed in the
singletest.pyandbuild_release.pyscripts (both of which are used in mbed 2 CI). This PR adds the missing configuration.Status
READY
Migrations
If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.
NO
Related PRs
Extending work done in #2802
Todos