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/