I need on the same project on two different machine: Windows and Mac. What to git track?

[ubaldot]

My idea is to git track the following folders

Core

Drivers

Middleware

and the two *.ld files so that I should be able to work seamlessly on both the Windows and Macos machines.

However, I am not sure if I should track also the .ioc file. Any hints? 

[Pavel A.]

Of course you want to keep the .ioc file in git. It is not required for building the C/C++ project but contains important information that you want to keep. This file is required to edit the configuration/pinout and re-generate initialization code in CubeMX or CubeIDE "device configuration tool". 

In the former items, you need also the .project and .cproject files (normal files in Windows but hidden in Unix ).

Of the two .ld files usually you want only one that is actually used (either ROM or RAM-based).

 

[ubaldot]

Thanks!
The problem, at least with .project, is that it is platform specific. I setup a project with macos and tried to open it in Windows and it just failed. I think because there are info about paths for the shell used for building the code that is obviously different on different platforms.

Hence, my idea was just to share the source code (and the .s and .ld files) leaving platform specific stuff (such as the .project file) out of git. My only worry is about the .ioc file, if it is actually platform independent. But I don't think so. 

[Pavel A.]

> The problem, at least with .project, is that it is platform specific.

Eclipse CDT supports cross-platform projects and platform-independent project files. Even though CubeIDE as-is does not ensure this automatically, one can "fix" the Eclipse project manually (or with 3rd party tools) so that it works on Windows and Linux (and on MacOS too, though I haven't tried that). It is also easy to break portability by introducing Windows-specific stuff - a path like "C:\\Users\something", DOS commands in pre/post build scripts, etc. So if you need portability,  1. do right things; 2. avoid wrong things.

 

[ubaldot]

> It is also easy to break portability by introducing Windows-specific stuff - a path like "C:\\Users\something"

That is the thing, this is why I was thinking to share only the source code and leave everything else out, with the exception of the .ioc because "perhaps" I was thinking it could work as-is in both the platforms and that was all the core of my question. Perhaps you may want to re-read my question 3-4 millions of times before claiming:

> So if you need portability,  1. do right things; 2. avoid wrong things.

because I cannot really see how such priceless advice helps in improving the discussion by any means nor how constructive can it be. 

[Pavel A.]

The Eclipse project files (.project, .cproject) are very important. All the crucial things are defined there: preprocessor definitions, include paths, libraries and so on. This definitely should be in the version control. IMHO it is easier to "fix" the project once and maintain it in good state, than re-create project on other system and then synchronize back and forth.

"Fixing" includes Windows back slashes and drive letters in paths. Convert all paths to Unix style. On Windows Eclipse will correctly translate Unix paths to native form. Avoid using platform specific paths. Use paths that look same on Windows and Mac, except the slashes. That's basically all. I did this many times on Windows and Linux, it works.

Debugger/run configurations (.launch)  also are bound to concrete machines, but they are simpler to redo from scratch. So these IMHO can be omitted from version control. 

 

[ubaldot]

Thank you for your reply. 
If you are aware of any guidelines I would appreciate if you can link me to them. Or, if not too many steps are required, you can write here how to proceed. 

Regarding the paths, they are essentially the same on macos and windows: 

~/Documents/embedded/stm32_workspace/my_project

 

[ubaldot]

In the meantime I will try to read the content of both .project and .cproject 

[ubaldot]

I think I found another solution for sharing projects among different platforms but this would rule out CubeIDE.
The solution is to use CubeMX instead and generate a project with IDE /Toolchain: Makefile and then to track only those generated files. In this way it should be possible to work with the preferred editor (vscode, vim, emacs, but also CubeIDE I think if one creates a new project based on an existing .ioc file - the one generated by MX, I gotta try it ).

I took a look at the generated Makefile and I was able to build with the following:

make GCC_PATH=/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin | grep warning 

The only problem I had are few warnings that I report next. Shall I be worried? 

Next, I would like to have a command line command for flashing the MCU. I know I can use STM32Programmer_CLI but I don't know exactly what to pass to it. Once I will find it I could add the option "upload" to the generated makefile so that I can use make upload to flash the MCU. Does it make sense?

$ make GCC_PATH=/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin | grep warning
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(libc_a-closer.o): in function `_close_r':
(.text._close_r+0xc): warning: _close is not implemented and will always fail

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(libc_a-lseekr.o): in function `_lseek_r':
(.text._lseek_r+0x10): warning: _lseek is not implemented and will always fail

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(libc_a-readr.o): in function `_read_r':
(.text._read_r+0x10): warning: _read is not implemented and will always fail

/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.macos64_1.1.100.202310310803/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc_nano.a(libc_a-writer.o): in function `_write_r':
(.text._write_r+0x10): warning: _write is not implemented and will always fail

[ubaldot]

To me more precise: in the Project -> Project Manager I selected "Copy all used libraries into the project folder" and "Generate peripherals initialization as pairs of '.c/.h' per peripheral" just to add some robustness and to be sure that I won't miss anything. 

[Pavel A.]

Re. a makefile and STM32Programmer_CLI for programming - both are good ideas. STM32Programmer_CLI has documentation, just in case somebody will wonder how to use it))

 

>  I selected "Copy all used libraries into the project folder" ...  just to add some robustness and to be sure that I won't miss anything. 

Yes this adds robustness, in a sense that all source files are contained in the project tree. But consider that these library files are updated by ST, then you'll have to update these files in your project as well.

 

Re. these warnings like "warning: _close is not implemented and will always fail": this is a known issue with the runtime library, should be fixed in next version. Meanwhile you can ignore these warnings (because no one uses _close, _exit etc. in embedded  software, nobody cares that they may fail) - or use an older toolchain that does not have this issue.