Mbed-cli: mbed_rtos_storage.h moved

[j3270]

The following commit on mbed-os is causing problems for mbed-cli, at least for me. Is anyone else having this problem?

https://github.com/ARMmbed/mbed-os/commit/ac22225ad9144718078fcb8c2fe7e65a04246151#diff-23b8db6c62efb5554fd96345537aea4c

If I use mbed-os 5.5.6, mbed-cli works just fine, but if I use the master branch ombed-os, mbed-cli doesn't work.

I am using mbed-cli 1.2.0 on both Windows and macOs.

Thanks,

[theotherjimmy]

hi @j3270,

This is likely a problem with mbed-os, if it's a problem (I can't reproduce it). Further, you have not described what problem is occurring when you switch. What do you expect to see happen? what is actually happening?

[j3270]

Hello @theotherjimmy,

The problem is,
[Fatal Error] rtos.h@28,0: mbed_rtos_storage.h: No such file or directory
[ERROR] In file included from ../../libs/mbed-os/mbed.h:20:0,
from ../../libs/MAX14690/MAX14690.h:37,
from ../../libs/MAX14690/MAX14690.cpp:34:
../../libs/mbed-os/rtos/rtos.h:28:31: fatal error: mbed_rtos_storage.h: No such file or directory
compilation terminated.

I would like to see mbed-cli updated to address the new project directory structure for the master branch of mbed-os, or mbed-os to revert back to the old structure. Which ever you guys see best.

The issue does not happen if you create a new mbed-cli project that imports a copy of mbed-os, which is not pulling from the master branch of mbed-os from what I can tell by comparing the project directory structure of what is pulled in, to that of the master branch.

The issue happens when you have your libs in a remote directory to your program; i.e using the
--create-only option, which is what I do. I do this because I do not want a new copy of mbed-os/mbed 2.0, every time I create a new demo. I like to have one copy of the libs I use in a separate location and I maintain them there. This does require a little more effort when compiling, but I just script that. I have another question about that, but don't know if this is the appropriate place for that question, because it is truly a question and not an issue. Which forum is best for questions? Last time I checked there are a couple.

Just to be clear, I don't believe my workflow is the issue. My workflow works just fine if I reference the tagged release of mbed-os-5.5.6 vs the master branch of mbed-os. Mbed-os-5.5.6 has the old directory structure. The new structure was introduced on August 31st as noted above.

Thanks for your help,

[theotherjimmy]

I would like to see mbed-cli updated to address the new project directory structure for the master branch of mbed-os,

Mbed CLI has no understanding of project structure outside of .lib and .bld files and configuration. This is an mbed OS issue.

[theotherjimmy]

I have another question about that, but don't know if this is the appropriate place for that question, because it is truly a question and not an issue

Open an issue. Yes, "issue" is not the right name, but whatever.

[j3270]

@theotherjimmy

So should I raise this issue on mbed-os?

[j3270]

That team may just say it is an embed-cli issue...

[theotherjimmy]

@j3270 The distinction between what is an mbed OS issue and what is an mbed CLI is not entirely clear to the user, so I can understand your team's point of view. Don't bother opening an issue on mbed OS, we can discuss it here just as well.

[theotherjimmy]

Here's what I think is happening:
~1) You create a .a from mbed OS~
2) You make a new project with --create-only
3) This new project has no mbed OS tooling (where the build code lives) So mbed CLI copies the mbed 2 tools to the project
4) The mbed 2 tools do not search for TARGET_CORTEX symbols in mbed OS, because they have not been updated to (it's not yet on a released version of mbed OS, which is where I generate the mbed 2 tools from)

So, to some extent this is _releated_ to your workflow. To some degree, this is also related to mbed 2 tool never being up to date with the master of mbed OS. This fact, combined with your workflow create the problem.

[theotherjimmy]

A workaround could be to symlink your dependent libraries, but that may not be possible on every platform.

[geky]

Symlinks do not work on Windows XP. If you don't care about that platform, it should be a good workaround.

[j3270]

So, to some extent this is releated to your workflow. To some degree, this is also related to mbed 2 tool never being up to date with the master of mbed OS. This fact, combined with your workflow create the problem.

@theotherjimmy, your outline of my workflow is correct and I agree with the diagnosis of the problem.

I have a question, when someone pulls from the mbed-os repo using the online tool, or mbed-cli, what is pulled in? It doesn't appear to be the latest commit in the master branch (at least for mbed-cli, I haven't checked the online tool yet)?

Is it the latest tagged release, like this one here? Which has been released while we have been talking this morning.

[theotherjimmy]

what is pulled in?

Whatever is mentioned in the files ending with .lib or .bld where the syntax for mentioning a repo is:

(https?|ssh)://<remaning-url>#[a-fA-F0-9]+

Mbed CLI will pull the git repo from the url (using the protocol on the command line) and then attempt to checkout the revision hash after the #.

The online IDE will do almost the same thing. It further restricts the revisions to only be released versions of Mbed OS.

It doesn't appear to be the latest commit in the master branch (at least for mbed-cli, I haven't checked the online tool yet)?

Yep. If you follow the above, you will have trouble getting to the current commit on the master branch, as that's always a moving target.

Is it the latest tagged release, like this one here?

As mentioned above, that depends on the contents of the .lib file. If you start with an Mbed OS example (project starting with mbed-os-example-) then you will likely pull a version that has recently been updated to point to the latest revision of Mbed OS (5.5.7 as of the time of writing)

[theotherjimmy]

I hope that helps you sort things out. I'm happy to explain how things work. 😄

[theotherjimmy]

Which has been released while we have been talking this morning.

Yeah, we release frequently. This _should_ allow you to just track the releases, and stay mostly up to date with bug fixes. You can't ever be more than 2 weeks behind what's on master, as we back port bug fixes onto a patch release every 2 weeks.

[j3270]

Thanks a bunch, I will inspect the contents of a .lib file, which I don't see that often due to my workflow.

Your comments on the volatile nature of the master branch make sense. One more question. The tags don't necessarily come directly from the master branch, correct? If they do, why doesn't the tag from today match the new directory structure committed on August 31st? Also, sorry, when will the new directory structure be released, I think you will be concerned with that, correct?

[theotherjimmy]

The tags don't necessarily come directly from the master branch, correct?

Correct.

Also, sorry, when will the new directory structure be released, I think you will be concerned with that, correct?

When the new dir structure is released I will be able to make a release of the Mbed 2 tools that match it.

[j3270]

Thank you, I really appreciate your time this morning.

I think it is appropriate to close this issue.

[theotherjimmy]

Glad I could help. Just open another issue if you want more help or questions answered.

[j3270]

@theotherjimmy

From your comments above

Here's what I think is happening:
2)You make a new project with --create-only
3)This new project has no mbed OS tooling (where the build code lives) So mbed CLI copies the mbed 2 tools to the project
4)The mbed 2 tools do not search for TARGET_CORTEX symbols in mbed OS, because they have not been updated to (it's not yet on a released version of mbed OS, which is where I generate the mbed 2 tools from)

Now that there are two releases with the new mbed-os directory structure, will the tools that are pulled in when using the --create-only option be updated?

Currently, when using the --create-only option, the tools pulled in only support mbed-os-5.5.7 and below.

If there are no plans to update the tools, should the --create-only option be removed from mbed-cli?

Thanks,

[theotherjimmy]

@j3270 The mbed 2 tools were out of date, and have been updated. This should resolve any mbed 2 issues you run into.

If there are no plans to update the tools, should the --create-only option be removed from mbed-cli?

We update the tools.

[theotherjimmy]

Currently, when using the --create-only option, the tools pulled in only support mbed-os-5.5.7 and below.

TL;DR: Try again. I fixed it 😄

[j3270]

@theotherjimmy thank you, it works.

Is there a way to update the tools folder of my existing projects? I had to make a new project using the --create-only flag, of course, to test the fix which isn't a big deal, but if I could issue a command to update the tools that would be cool.

Thanks for updating the tools.

[theotherjimmy]

Is there a way to update the tools folder of my existing projects?

mbed deploy or mbed update should update the tools.

I'm going to close this issue as fixed.