Unnecessary doubled souce package

[tansy]

Found that sources fot windows and linux are separate and after closer inspection I can't shake the impression that it's unnecessary hastle. You have to generate two differenct packages which do not collide in any way anyway. One source package that includes everything is more than enough. One can generate relevant building scripts exacly same way as if they were separate.

Also maintaining DOS line endings (CRLF) is unnecessary either. Also irritating when seen or edited under *nix. Diff for that matter threats two same lines, but with different line endins, as different. Even microsoft doesn't use DOS endings any more. And for many years now.
It could be solved with simple `.gitattributes'. I can do that (i mean PR) if you accept that.

[dbry]

Thanks for the message!

Found that sources fot windows and linux are separate and after closer inspection I can't shake the impression that it's unnecessary hastle. You have to generate two differenct packages which do not collide in any way anyway. One source package that includes everything is more than enough. One can generate relevant building scripts exacly same way as if they were separate.

The idea is that the *nix tarball should take case of everything now. I used to have a separate source package for Windows, but that's going away for the next release.

Also maintaining DOS line endings (CRLF) is unnecessary either. Also irritating when seen or edited under *nix. Diff for that matter threats two same lines, but with different line endins, as different. Even microsoft doesn't use DOS endings any more. And for many years now. It could be solved with simple `.gitattributes'. I can do that (i mean PR) if you accept that.

Hmm. I have certainly not heard that Microsoft is ditching CRLF, but Visual Studio since at least 2019 certainly accepts both without an issue (although it will create new files with CRLF). In the WavPack sources any file edited within the last decade should be *nix line endings unless I missed one. There are certainly legacy files in there (some I did not even create) that might still have DOS endings, but is that really an issue? In any event, I would be happy to look at a .gitattribute file that "fixes" this.

[tansy]

Hmm. I have certainly not heard that Microsoft is ditching CRLF

Depends what you mean by 'ditch'. They still support it but not force it and not use it in their published sources, which were linked.

They don't not force it. If you use MSDEV from VC6 and read LF source, it will compile, problem, and will not be convertred into CRLF either. I was testing it and that's the result I got: zipped project, screenshot.
Only when you press enter it will add CRLF new line in that place. That's it.
I don't know about VC2019+ as I don't use it. MSDEV'98 I have explained above.

I would be happy to look at a .gitattribute file that "fixes" this.

I get the irony. It obviously will not 'fix' what is already in a repo, it would only 'fix' whatever is uploaded since.

file could look like this:

# Set the default behavior
* text=auto

# Explicitly declare source files
*.c text eol=lf
*.cc text eol=lf
*.h text eol=lf
*.sh text eol=lf

# Denote files that should not be modified
*.odt binary
*.pdf binary
*.png binary
*.wav binary
*.wv  binary
*.zip binary

# Visual Studio
*.dsp text eol=crlf
*.dsw text eol=crlf
*.sln text eol=lf
*.vcxproj* text eol=lf
*.vcproj* text eol=lf
*.suo binary
*.res binary
*.rc text eol=lf

or even * text=auto eol=lf and list binaries only.

When it comes to files in repository I would use the script that was designed to solve that problem before.
The result would look like this.

but is that really an issue?

If you decide to use .gitattributes it would be logical to 'normalize' the files before, or they will be somewhat mixed on the way, when any modifications occur.

[dbry]

I checked the repos and pretty much verified what I had guessed. The only files still using DOS endings are legacy files that I didn’t even create and that are really only present for historical reference (e.g., winamp/in.h) and also files generated by MSVC (e.g., wavpackdll/wavpackdll.rc). When I converted those to unix line endings and edited them with Visual Studio 2019 they ended up with mixed line endings, which I think is a little weird and undesirable.

I probably don’t fully understand this problem, and I appreciate your input, but at this point I think I’ll leave everything as is but keep the issue open as a reminder. Thanks!

Also some interesting/funny perspectives here.

[tansy]

Ok, ok, i get that. Maybe, at least .gitattributes, so if you edited them with Visual Studio 2019 they ended up with mixed line endings?

---

Also some interesting, funny predictive

It really is funny, because they use while bunch of slogans, to maintain status quo.
Like this one:

this behavior is hard-coded into hundreds of millions of apps, tools, scripts, etc. many of which will break if CRLF is replaced with LF, again,

Yeah, right. Even .bat files don't need to use CRLF, nor to mention anything else.

And that:

likely crashing millions of systems, businesses, and even several nations.

Made me rotfl.

[dbry]

And that:

likely crashing millions of systems, businesses, and even several nations.

Made me rotfl.

Exactly! I assume he means that it would only crash fairly small nations... 😸