2025-03-19 2:39 AM - last edited on 2025-03-20 4:23 AM by Andrew Neil
Code generated by CubeMX use Windows line-endings, which generate huge problems under other operating systems (repository, editors, etc.). You have to strip CR-LFs after every code generation.
Somebody should use standard method of platform-independent text file generation (StringBuffer and System.lineSeparator()).
2025-03-19 4:19 AM
What are these huge problems that it causes? Why do you need to strip CRLF on every line? Compilers don't have an issue with line endings.
2025-03-19 4:46 AM
repository, editors, every Linux script interprets this as a double new-line, etc.
please use commonly known standards
2025-03-19 5:00 PM - edited 2025-03-20 2:55 PM
Cube does not create or modify any linux scripts. If you have such scripts in the project repository please define them in the .gitattributes to keep them as is.
Decent modern editors do not have problems with CRLFs.
But it may have sense to generate all source files with Unix LF line endings because Windows tools don't need CRLFs anymore. On Windows 11 notepad nicely opens unix style files. Some Windows specific files still have to be CRLF, but again, Cube does not generate them. Use .gitattributes.
2025-03-20 3:12 AM
MX genarates LINKER scripts, sources, etc.
These sources are interpreted by various programs and scripts, which do not accept CRLF.
Simple getline in c++ will return TWO lines for every CRLF.
We have written some software, which makes corrections after MX havoc.
Please fix it, simply. Make it platform-independent, as whole world does.
2025-03-20 3:48 AM
"Use .gitattributes."
Sorry, do not fix your bugs in my repository.
A have many different sources in repository, even Microchips.
Do I have to transfer all parts of the project to Windows ??!
2025-03-20 4:22 AM
Surely, a Git repo should be oblivious to this?
The client should take care of it.
2025-03-20 4:33 AM
You are not right, again.
I have several parts of a project in one repository.
There is no possibility to set a switch for one part and another in second part.
Please fix it. It is literally 3 lines of code. This whole "discussion" was not worth of it.
2025-03-20 4:44 AM
Incorrect:
Git always uses unix-style line endings internally - it is the client which manages conversion to the host system's style:
https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings
2025-03-20 4:50 AM
Please do no teach me how git works.
I'm 100% sure I know better internals of git than you.
Please fix the bug - it is VERY annoing.