ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.98k forks source link

[project.py] is broken #1919

Closed ohagendorf closed 8 years ago

ohagendorf commented 8 years ago

After PR #1893 project.py does not work any longer. The generated zip files are nearly empty or an exception is generated. In the following some examples:

Exporting to gcc:

python project.py -m NUCLEO_F401RE -i gcc_arm -p 28
Traceback (most recent call last):
  File "project.py", line 213, in <module>
    tmp_path, report = export(project_dir, project_name, ide, mcu, project_dir, project_temp, clean=clean, zip=zip, extra_symbols=lib_symbols, relative=sources_relative)
  File "E:\GitHub\mbed\tools\export\__init__.py", line 105, in export
    exporter.generate()
  File "E:\GitHub\mbed\tools\export\gccarm.py", line 150, in generate
    self.gen_file('gcc_arm_%s.tmpl' % self.target.lower(), ctx, 'Makefile')
  File "E:\GitHub\mbed\tools\export\exporters.py", line 169, in gen_file
    open(target_path, "w").write(target_text)
IOError: [Errno 2] No such file or directory: 'E:\\GitHub\\mbed\\.build\\export\\.temp\\Makefile'

Exporting to coide

python project.py -m NUCLEO_F401RE -i coide -p 28
Traceback (most recent call last):
  File "project.py", line 213, in <module>
    tmp_path, report = export(project_dir, project_name, ide, mcu, project_dir, project_temp, clean=clean, zip=zip, extra_symbols=lib_symbols, relative=sources_relative)
  File "E:\GitHub\mbed\tools\export\__init__.py", line 105, in export
    exporter.generate()
  File "E:\GitHub\mbed\tools\export\coide.py", line 110, in generate
    self.gen_file('coide_%s.coproj.tmpl' % target, ctx, '%s.coproj' % self.program_name)
  File "E:\GitHub\mbed\tools\export\exporters.py", line 169, in gen_file
    open(target_path, "w").write(target_text)
IOError: [Errno 2] No such file or directory: 'E:\\GitHub\\mbed\\.build\\export\\.temp\\MBED_BLINKY.coproj'

Exporting to uvision/uvision5:

cc @screamerbg @theotherjimmy @sg- @0xc0170

ohagendorf commented 8 years ago

with a manual created '.temp' dir the execption disappears but that works just once because it is deleted after exporting

and the generated gcc_arm/coide zip project files are nearly empty like the uvision/uvision5 files

I'm using Windows 10, maybe under linux it is working ...

0xc0170 commented 8 years ago

I just merged #1912 , that should solve it . Please rerun , and let us know. I tested gcc arm and uvision.

0xc0170 commented 8 years ago

@ohagendorf coide exports, but seems like c99 is not enabled there (I tested with kl25z as I built the lib earlier). Can you please provide details if you find anything?

0xc0170 commented 8 years ago

I am seeing weird errors from various IDE, for instance LPC1768 for uvision with full sources, it does not compile. It complains about i2c_start not defined, that seems correct as it's defined as inline i2c_start() in the C code file. according to c99, it should be private to that compilation unit. But I have not seen this error, neither others I am seeing now. All this is for uvision, I'll need to investigate

ohagendorf commented 8 years ago

Additional to missing i2c_start and i2c_stop I've got several other Undefined symbols. With several

#ifdef __cplusplus
 extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif

in hal_tick.c, system_stm32f7xxx.c and mbed_overrides.c around the function declarations of HAL_IncTick, us_ticker_irq_handler, HAL_Init the first problem was solved. The i2c_start and i2c_stop problem could only be solved be removing inline

0xc0170 commented 8 years ago

@ohagendorf Does that look like c files are compiled with c++ compiler? To me that would be the only explanation to some errors I am seeing, but could not spot the change causing this in the code base.

ohagendorf commented 8 years ago

No, in the project file they are all FileType 1, same as the other .c files. Filetype 8 is used by .cpp files. So that could not be the reason.

0xc0170 commented 8 years ago

I probably spot the issue , there's --cpp flag for cxx flags, which is fine for cxx ,but in the exported project is set for c/c++ and that's the problem. In the docs on keil site This option is implicitly selected for files having a suffix of .cpp, .cxx, .c++, .cc, or .CC. means we don't need this option anyway. Once you remove it , lot of errors are gone for me with various projects. I'll prepare a fix

ohagendorf commented 8 years ago

Thanks for the fast solution.

0xc0170 commented 8 years ago

It's still broken, at least if I generate a project with full sources there're duplicated symbols (.o files and also sources, thus like system , startup or others are duplicated). We have to investigate

cc @screamerbg

ohagendorf commented 8 years ago

I don't have problems with something like this:

project.py -m NUCLEO_F767ZI -i uvision5 -p 28 or project.py -m NUCLEO_F767ZI -i gcc_arm -p 28

as I had before.

0xc0170 commented 8 years ago

I Am closing this, as it was resolved. the issue I reported here , I created a separate ticket for it to track it.