Re: [boost] [1.64][process] Windows line endings in headers

Subject: Re: [boost] [1.64][process] Windows line endings in headers
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-04-22 11:51:17

>>> This is surprising.. Since we debugged EOL issues with the automated
>>> release building long ago. And of course, we spent some time explicitly
>>> finding a way to have consistent EOLs.
>>
>> The problem is that it doesn't have a .gitattributes file. Maybe this could
>> be tested for in the 'check library' test?
>>
> 
> Adding to the library check is certainly possible.

I have to own up that the EOL support during the Boost git migration was
never finished, and some of that is my fault as I did what EOL
conversion there was and is.

The reason it was never finished was due to a list of tricky corner cases:

1. We can't insist on a canonical .gitattributes per subrepo because
.gitattributes can do lots of cool other stuff like change merge
strategies for some files only. There were also some Boost libraries
that specifically exempt specific files from CRLF because they are test
input for the test suite.

2. Similarly, we can't insist on a canonical CRLF for source files
either, again, because of test input for the test suite for some libraries.

3. We should really have documented/added a build check that every new
Boost library - AND its subrepos - needs a .gitattributes containing at
least the lines in:

https://github.com/ned14/boost.afio/blob/master/.gitattributes

(optionally sans the svneol=* stuff, as that is probably legacy now. You
may note I don't use the Boost standard .gitattributes. That's because
Boost took my standard .gitattributes back some years ago, and I've
since fixed a few bugs in it. I'd suggest Boost fuse my latest with its
latest)

4. HOWEVER adding a .gitattributes to a repo with incorrect or
mismatched CRLF leads to nasty surprises for everybody. I can speak from
experience where you just can't check in a file because git says it
hasn't changed, even though it clearly has because you just changed it.
The cause is confusion in the CRLF logic.

5. On top of this, I personally have run into a new problem with the
Windows Subsystem for Linux of late which is amazing and if you're not
using it yet, you should start, but comes with the big problem that the
WSL layer thinks it's Unix yet you've probably checked out the repo in
Windows. If you're flipping between toolings, you'll end up with mixed
CRLF in files unfortunately. I point a finger at clang-tidy with its
automated fixes right now as a particular culprit.

6. So what really needs to happen is that someone needs to write a
.gitattributes parser which then goes and applies those CRLF checks
across every file mentioned in the .gitattributes and check it is
correct because the one in git is buggy. That was work I wasn't able to
do at that time having just started a new job. Hence the git migration
was unfinished. I keep meaning to write one myself as I keep getting
bitten here with the loss of hours of productivity, but it'll be in
Python3 and not suitable for Boost.Build.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/