On 20 April 2017 at 16:14, Rene Rivera via Boost < boost@wowbagger.crest.iu.edu> wrote:

...

I can see some of the headers in Boost.Process (for example, boost/process/cmd.hpp, boost/process/env.hpp) contain Windows line endings.

Is it an issue? I'm surprised. VS deals with Linux or Apple (what were they thinking in Cupertino?) line-endings just fine. Windows' notepad doesn't, but there is a far superior replacement https://xhmikosr.github.io/notepad2-mod/, which does (and deals with many other issues (like encodings) too). degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On 20 Apr 2017 15:15, "Rene Rivera via Boost" wrote:

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?

On 20 Apr 2017 15:34, "Andrey Semashev" wrote:

On 04/20/17 17:32, Daniel James via Boost wrote:

...

On 20 Apr 2017 15:15, "Rene Rivera via Boost" <

boost@wowbagger.crest.iu.edu>

...

wrote:

...

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.

I was under impression that the superproject's .gitattributes should be in effect in this case. Is it not?

I don't think so, but I haven't checked. Even if it is then that's not reliable as commits might be made outside of the superproject

...

...

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/

On Thu, Apr 20, 2017 at 9:57 AM, Klemens Morgenstern via Boost < boost@wowbagger.crest.iu.edu> wrote:

Am 20.04.2017 um 12:59 schrieb Andrey Semashev via Boost:

...

Hi,

I can see some of the headers in Boost.Process (for example, boost/process/cmd.hpp, boost/process/env.hpp) contain Windows line endings. Regarding 1.64, Windows line endings are also present in the .tar.bz2 package, which is supposed to be targeted for POSIX systems.

1. Could Windows line endings be removed in git?

2. Could the release procedures be updated to ensure that foreign line endings don't creep into the released packages?

I understand that 1.64 has sailed, but I think at least a note (preferably, with a patch) would be appropriate in the release notes.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Let me please state, that I am really sorry for causing this inconvenience. I wasn't even aware of this problem until it was too late. I am also not sure how this happened, because my windows setup is correct, i.e. replaces that to the linux line endings.

Since process is C++11 only, I don't know which current compiler would have problem with that though.

I'll get this fixed until the next release; if there is to be a 1.64.1 I'll get it done before that.

We almost never to point releases.. There have to be serious problems that affect many for that to happen. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail