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

[TDK]

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.

[trzeci]

repository, editors, every Linux script interprets this as a double new-line, etc.

please use commonly known standards

[Pavel A.]

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.

 

[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

 

[clonephone82]

Hi, any news here? I have no the problem on windows that it generates only LF with the latest version.

[w475241512]

me too！

[Pavel A.]

It would be nice to configure (have option to generate this or that) but IMHO the era of non-Unix line endings is over. All decent software tools are comfortable with LFs only (and UTF-8 instead of anything else).

In your git repo you can just disable the "translation" with this .gitattributes file:

* -text

 

[Mikk Leini]

I just did the same with a batch file and AI generated powershell script:

Need to call post_gen.bat from CubeMX as a post-processing user action. Working directory for script is the IOC file directory.

post_gen.bat shall be placed in the same folder as IOC file. Content:

powershell .\post_gen.ps1

And then post_gen.ps1 also into same folder:

function Convert-ToCRLF {
 param(
 [Parameter(Mandatory = $true)]
 [string]$SubPath
 )

 $fullPath = Join-Path -Path (Get-Location) -ChildPath $SubPath

 if (-not (Test-Path $fullPath)) {
 Write-Host "Path not found: $fullPath"
 return
 }

 Write-Host "Processing folder: $fullPath"

 Get-ChildItem -Path $fullPath -Recurse -Include *.c, *.h, *.txt, LICENSE |
 ForEach-Object {
 Write-Host "Converting $($_.FullName)"
 $content = Get-Content $_.FullName -Raw
 $content = $content -replace "`r?`n", "`r`n"
 Set-Content $_.FullName $content -NoNewline
 }
}

# Fix line ending to Windows style
Convert-ToCRLF "Drivers/CMSIS"
Convert-ToCRLF "Drivers/STM32N6xx_HAL_Driver"
Convert-ToCRLF "Middlewares/ST"

But some license file has some odd characters that it screws up. That wasn't UTF-8 encoding. So it's not perfect. I solved that with a git restore command in the batch file.