BuildSys - autocrlf

Hi, may I pass on a few suggestions for the BuildSys – basically due to oddities I was experiencing:

When you use git on windows it will by default amend the line endings from LF to CRLF. Sounds harmless, bis a pain since Perl and DDE cc can’t cope with that in some cases:

• For one the Library.Build.Hdr2H perl script uses so-called “here documents”, i.e. a command like print OUT<<END which indicated that all subsequent lines up to one containing just the string “END” will be printed to OUT. But if line endings are CRLF then Perl fails to find the line with the word END since I assume it sees jut a line containing “END” plus the CR character (i.e. does not ignore the CR).

• The other one having problems with CRLF is the C compiler in DDE since for multi-line ##defines that use the backslash at the end of the line as continuation character cc seems to fail to detect the backslash since I assume it sees the backslash and CR and is not accepting that.

So my suggestion is to prominently include in the guide the command “git config —global core.autocrlf false” for Windows users.

In addition perhaps the Build app can read some text file that was fetched from git (be it some source code file or perl script) and check that the line endings are just LF and if they are not to tell the user that the aforementioned git config command should be run before using git.

The other one having problems with CRLF is the C compiler in DDE since for multi-line ##defines that use the backslash at the end of the line as continuation character cc seems to fail to detect the backslash since I assume it sees the backslash and CR and is not accepting that.

Might have been 1989 when I reported that…

git config —global core.autocrlf false

Wouldn’t autocrlf input be better in case the file is tweaked in a Windows editor that introduces a CRLF?

if you use a decent text editor in Windows like Notepad++ it does not change the line endings or the encoding unless you ask it to do so explicitly.

if you use a decent text editor in Windows like Notepad++ it does not change the line endings or the encoding unless you ask it to do so explicitly

Setting it to be the default text editor of the OS is icing on the cake.

Requiring a configuration like that on individual repositories is the wrong way to approach such problems – it means that you require users to configure things correctly and if they don’t you introduce broken content.

If you want a specific file (or class of files) to have a specific line ending format, the correct way to do so is to configure the specific file (or class of files) in the .gitattributes file so that the files are always formed properly, regardless of the user’s configuration.

*,102 text=lf
*.pl text=lf

Nice idea Charles – but not quite what I’d suggest, I dare say!

Normally if I use a Windows based environment git changing the line endings to the default of the OS I use is even a good idea (though with a decent text editor the line endings can be LF or CRLF on Windows); if I’d use a Linux based setup same applies.

But we do things weird since there is no git client that I am aware of for the platform to use (RISC OS) so we have to run git in some alien system and then copy the files over – and thus need to be aware of such oddities and figure out how to address them – rather on some global level since there are lots of text files (or files git might consider to be text), be it Perl scripts, C or Assembler sources, obey files, or whatever… to adding rules for them all to the .gitattributes might be a bit demaning or even miss out the odd one.

Basically nowadays I’d even expect that some tool using text files should get along with different line endings since LF as well as CRLF are very common and cross platform file transfer is pretty common – but since at the time being we do not have that so asking git to not adjust the line endings to Windows format is probably the easiest way to got – apart from using it inside WSL or with native Linux.

According to the documentation a .gitattributes file of the form:

  * -text

Asking a user to change a global attribute could have knock on effects on other repositories they’re using. If It’s something that is required for the repository, it should be specified in the repository.

-text is not what you want though, surely?

That will disable all end of line processing, which will mean that when you edit files on Windows you run the risk of adding in CRLF sequences which will then break other platforms.

Of course, most modern editors will be just fine with adding only the endings that are appropriate to the file you’re editing, so maybe that is unlikely. In any case, I wouldn’t apply such a thing to *.