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.

[SJB]

Any news on ticket number 217250 ?

I have a similar problem when checkout a project from git on macOS - the files come in with native line endings (LF) as that's how they are stored in git (there a global gitattibuses that enforces this). But when I re-generate them from within STM32CubeMX (for example after a setting change) many of the files, but not all, get created with Windows line ending (CR LF).  For example,,,

% file Core/*/*.[c,h] Drivers/*/*/*.[c,h] 
Core/Inc/main.h:                                           c program text, ASCII text, with CRLF line terminators
Core/Inc/stm32f3xx_hal_conf.h:                             c program text, ASCII text, with CRLF line terminators
Core/Inc/stm32f3xx_it.h:                                   c program text, ASCII text, with CRLF line terminators
Core/Src/main.c:                                           c program text, ASCII text, with CRLF line terminators
Core/Src/stm32f3xx_hal_msp.c:                              c program text, ASCII text, with CRLF line terminators
Core/Src/stm32f3xx_it.c:                                   c program text, ASCII text, with CRLF line terminators
Core/Src/syscalls.c:                                       c program text, ASCII text
Core/Src/sysmem.c:                                         c program text, ASCII text
Core/Src/system_stm32f3xx.c:                               c program text, ASCII text
Drivers/CMSIS/Include/cmsis_armcc.h:                       c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/cmsis_armclang.h:                    c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/cmsis_compiler.h:                    c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/cmsis_gcc.h:                         c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/cmsis_iccarm.h:                      c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/cmsis_version.h:                     c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_armv8mbl.h:                     c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_armv8mml.h:                     c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm0.h:                          c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm0plus.h:                      c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm1.h:                          c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm23.h:                         c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm3.h:                          c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm33.h:                         c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm4.h:                          c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_cm7.h:                          c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_sc000.h:                        c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/core_sc300.h:                        c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/mpu_armv7.h:                         c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/mpu_armv8.h:                         c program text, ASCII text, with CRLF line terminators
Drivers/CMSIS/Include/tz_context.h:                        c program text, ASCII text, with CRLF line terminators
Drivers/STM32F3xx_HAL_Driver/Inc/stm32f3xx_hal_cortex.h:   c program text, ASCII text
Drivers/STM32F3xx_HAL_Driver/Inc/stm32f3xx_hal_def.h:      c program text, ASCII text, with CRLF line terminators
Drivers/STM32F3xx_HAL_Driver/Inc/stm32f3xx_hal_dma_ex.h:   c program text, ASCII text
Drivers/STM32F3xx_HAL_Driver/Inc/stm32f3xx_hal_dma.h:      c program text, ASCII text
....

The problem is that git then sees them as changed files when in reality maybe only a few lines in one file have changed:

% git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   Core/Inc/main.h
	modified:   Core/Inc/stm32f3xx_hal_conf.h
	modified:   Core/Inc/stm32f3xx_it.h
	modified:   Core/Src/main.c
	modified:   Core/Src/stm32f3xx_hal_msp.c
	modified:   Core/Src/stm32f3xx_it.c
	modified:   Drivers/CMSIS/Include/cmsis_armcc.h
	modified:   Drivers/CMSIS/Include/cmsis_armclang.h
	modified:   Drivers/CMSIS/Include/cmsis_compiler.h
	modified:   Drivers/CMSIS/Include/cmsis_gcc.h
	modified:   Drivers/CMSIS/Include/cmsis_iccarm.h
	modified:   Drivers/CMSIS/Include/cmsis_version.h
	modified:   Drivers/CMSIS/Include/core_armv8mbl.h
	modified:   Drivers/CMSIS/Include/core_armv8mml.h
	modified:   Drivers/CMSIS/Include/core_cm0.h
	modified:   Drivers/CMSIS/Include/core_cm0plus.h
	modified:   Drivers/CMSIS/Include/core_cm1.h
	modified:   Drivers/CMSIS/Include/core_cm23.h
	modified:   Drivers/CMSIS/Include/core_cm3.h
	modified:   Drivers/CMSIS/Include/core_cm33.h
	modified:   Drivers/CMSIS/Include/core_cm4.h
	modified:   Drivers/CMSIS/Include/core_cm7.h
	modified:   Drivers/CMSIS/Include/core_sc000.h
	modified:   Drivers/CMSIS/Include/core_sc300.h
	modified:   Drivers/CMSIS/Include/mpu_armv7.h
	modified:   Drivers/CMSIS/Include/mpu_armv8.h
	modified:   Drivers/CMSIS/Include/tz_context.h
	modified:   Drivers/STM32F3xx_HAL_Driver/Inc/stm32f3xx_hal_def.h
	modified:   STM32F303XX_FLASH.ld
	modified:   nucleo-f303k8-vscode.ioc

I could use a .gitattributes file to manage this but what are rules as to which file get LF and which get CR LF line endings?

One rather kludgy solution is to run a script to convert them all back to unix (LF) endings after every use of STM32CubeMX

I’m using this  script...

#!/bin/bash
# convert all the generated files to unix (LF) line endings

DOS2UNIX=/opt/homebrew/bin/dos2unix

$DOS2UNIX *.ld

$DOS2UNIX Core/Inc/*.h
$DOS2UNIX Core/Src/*.c
$DOS2UNIX Core/Startup/*.s

$DOS2UNIX Drivers/CMSIS/Device/ST/*/include/*.h
$DOS2UNIX Drivers/CMSIS/Include/*.h

$DOS2UNIX Drivers/STM32F3xx_HAL_Driver/Inc/*.h
$DOS2UNIX Drivers/STM32F3xx_HAL_Driver/Inc/Legacy/*.h
$DOS2UNIX Drivers/STM32F3xx_HAL_Driver/Src/*.c

This could be added to the After Code Generation User Actions in SM32CubeMX, but that makes the .ioc file non portable (and I have a mix of macOS Window users).  Instead, my macOS users have to remember to run this before committing.

I’m now thinking probably need another script for my Windows uses (I’m on macOS right now so can’t check)

A fix in STM32CubeMX so that it always generated LF line endings on all platforms would be great.  I’d even be happy with Windows generating files with CR LF as git will convert them to LF on commit.  Even better would be a setting in STM32CubeMX to allow me to pick.