Line endings - bug in CubeMX, all versions

[trzeci]

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()).

[Pavel A.]

With more positive attitude and if you won't mind calling this bug 'feature request' this may get traction ))

@STTwo-32  ??

IIRC readline() can be configured to ignore CR with ~/.inputrc or some rl_... function.

[trzeci]

Is it this moment when you realized it is a feature not a bug?

I still need it to be fixed.

[montea]

This is indeed VERY annoying. We have people using this on multiple machines and after every CubeMX generation we get 100 files changing just because of the line endings... Please not call this a feature :) 

[mƎALLEm]

Hello,

The behavior has been escalated internally for analysis with an internal ticket number 217250 not accessible by the community users.

[JesperEC]

Hi @mƎALLEm!

Please let me share one more data point for this that would be great if it was added to the internal ticket.

When generating code for CMake build setup with STM32CubeMX 6.16.0, it turns out that NonSecure/mx-generated.cmake and Secure/mx-generated.cmake uses all 3 kind of line endings: \n, \r and \r\n. This makes it a bit hard to handle conversion of these files to the format you want and causes clutter in many diff tools. It would be better if it used 1 kind of line endings even if it is not the platform specific one.

As a side note it also seem to mix indenting with spaces and tabs.

Reproduced on Windows 11 and Debian bookworm.

I have attached the .ioc and the generated cmake-file.

Best regards, Jesper