mbed export fails with switch "--source .."

[Alex-EEE]

Hi,

I'm trying to export while also including source files in the parent directory of my mbed program. The following fails:

C:\files\mbed\sandbox\framework\mbed> mbed export --source .. -i IAR
Scan: ..
Scan: FEATURE_LWIP
Scan: FEATURE_STORAGE
Traceback (most recent call last):
  File "C:\files\mbed\sandbox\framework\mbed\mbed-os\tools\project.py", line 259, in <module>
    main()
  File "C:\files\mbed\sandbox\framework\mbed\mbed-os\tools\project.py", line 254, in main
    build_profile=profile, app_config=options.app_config)
  File "C:\files\mbed\sandbox\framework\mbed\mbed-os\tools\project.py", line 96, in export
    app_config=app_config)
  File "C:\files\mbed\sandbox\framework\mbed\mbed-os\tools\export\__init__.py", line 358, in export_project
    copyfile(static_file, join(export_path, basename(static_file)))
  File "C:\Python27\lib\shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'C:\\files\\mbed\\sandbox\\framework\\mbed\\mbed-os\\tools\\export\\.mbed'

[theotherjimmy]

@Alex-EEE That's going to try to scan the current directory twice... You many want to just run the export from the directory above instead.

[theotherjimmy]

That being said, I don't know why you would be getting that error, unless you deleted the .mbed file from the tools directory.

[theotherjimmy]

@Alex-EEE You seem to have left off the mcu argument. I assume that you had the -m argument present, as it got passed argument parsing.

[Alex-EEE]

The command works when I run it "normally" (from the root of the mbed program) with no source switch. I was able to do mbed test -compile --source .. and pull in TESTS folders from the parent of my mbed program, so I thought maybe export would work as well. But perhaps export will be unhappy looking at folders that are not structured as mbed programs?
-MCU: I have it set in my global properties.

[theotherjimmy]

@Alex-EEE

folders that are not structured as mbed programs

I suppose that this is possible, but unlikely.

---

The error your seeing is quite odd, It's complaining about not being able to open a particular file, which exists.

I also expect that to work.

[theotherjimmy]

@Alex-EEE You may be able to work around this issue by putting a .mbed file in the C:\files\mbed\sandbox\framework directory.

[Alex-EEE]

So that let the export finish, BUT, it put the project file into ".." (makes sense), but it actually populated all the relative paths inside project file AS IF the project file was still in the root mbed directory ( the directory where I invoked mbed export ). I moved the project file to there and now all the relative links work.

Couple more questions:

1. How does mbed CLI "detect" if a folder is "an mbed program" That is, what does it "not see" when this happens:
   PS C:\files\mbed\sandbox\framework> mbed export
   [mbed] WARNING: Could not find mbed program in current path "C:\files\mbed\sandbox\framework".

2. What does .mbed contain? I see it indicates the target, what does key ROOT indicate?

[theotherjimmy]

1. the .mbed file

2. project local settings, including the ROOT element indicating the root of the project.

[Alex-EEE]

Workaround:

• Faking the root with .mbed is a no go b/c the cli toolchain expects mbed-os to either be directly beneath the execution directory, or in a parent of the execution directory.
• The exporter comes up with all the correct links relative to the mbed root, but then puts the project file into the target directory for --source (.. in my case) If you move the project back into mbed root, then this works AND, it captures all the source files in the parent ( ie my goal in using '--source ..' )

[ArjanSmit]

We are building an application which can be simulated under Windows/Linux. Mbed-os is only one part of the source tree and we need to build it using a Makefile as part of the "application project' loadcells and not within the instead of using the mbed-cli environment.
Project structure:
Root
| projects
- loadcells (application)
- loadcells_simulated (application simulated, no mbed-os)
| mbed-os
| extlibs
- liba

If multiple --source options are used the generated makefiles are placed in the first --source location
mbed export -i gcc_arm -m NUCLEO_L432KC --profile debug --source mbed-os --source projects\loadcells

[theotherjimmy]

Hi @ArjanSmit

I think that's enough information to let me know what's going wrong here. I'll see what I can do about this today. I think it may be a quick fix.

[theotherjimmy]

@Alex-EEE I think you may want to check out #626

[Alex-EEE]

@theotherjimmy thanks! @ArjanSmit you could also consider " --source .. "

[daid]

(FYI, I work with ArjanSmith on this project, #626 won't solve this problem)
@theotherjimmy @Alex-EEE "--source .." won't work because it would include the "simulation" sources.

I've looked a bit more into this, and I came to the conclusion that "--source" in the "export" function is just broken. Simple example, file structure:

mbed-os/
projects/projectA/main.cpp
projects/projectB/main.cpp

Then, executing mbed-cli export -i make_gcc_arm --source projects/projectA --source mbed-os in the root of this structure will result in a Makefile being made at:
projects/projectA/Makefile
However, this Makefile has paths that are relative to the location where mbed-cli is run, example:

SOURCES = mbed-os/* \
    projects/projectA/main.cpp

I would expect:

SOURCES = ../../mbed-os/ \
    main.cpp

Short version
So, short version, mbed-cli export generates paths relative to the current working directory, but stores the resulting export in the first source path. At which point at least the Makefile export no longer works (and thus the eclipse also fails)

FYI, running mbed-cli compile --source projects/projectA --source mbed-os does work correctly, making me think that this is proper use of --source. And that just the export is broken.