Update INSTALL

[Forelyl]

When building libpng with cmake on Windows with MinGW encounter problems due to usage of default setting of core.autocrlf on Windows. Because this errors may be found by ones who also install lib on Windows, I am proposing this change to INSTALL file, to provide support with this issue

[jbowler]

This is a general problem with cross-system source control systems. Unfortunately it cuts both ways; if the lf<->crlf auto stuff is turned off in a Windows environment patches will come in with line endings and the same problem will emerge the other way round. Ideally the source control system would not be dependent on any particular whitespace representation or indentation style etc.

This has been reported before and I think the original reporter ended up with the same fix (i.e. turning off on Windows) but similar problems including the inverse one have been seen several times.

It's not completely clear to my why it happens on Windows. I would expect awk to use <cr><lf> on Windows because that is the format of text files on Windows and I would expect the autocrlf therefore to need to be true, not false.

@Forelyl can you test this patch:

diff --git a/scripts/options.awk b/scripts/options.awk
index b74223ab7..563dd2f5e 100755
--- a/scripts/options.awk
+++ b/scripts/options.awk
@@ -29,6 +29,11 @@
 # are copied to the preprocessed file).

 BEGIN{
+   # This allows the line endings of the input file to be any combination
+   # of <CR><LF>.  Blank lines get removed but this is safe because they have
+   # no semantic interpretation.
+   RS="[\r\n][\r\n]*"
+
    out=""                       # intermediate, preprocessed, file
    pre=-1                       # preprocess (first line)
    version="libpng version unknown" # version information

Please note that the same patch would be required in the other two files scripts/*.awk; what I'm interested in is whether the build manages to build pnglibconf.h

[jbowler]

@ctruta: no answer means yes. Or not.

Depends how you want to run with this no-response stuff. Your contributors post bugs, you don't respond. I post an analysis, they don't respond.

No way out.

[Forelyl]

@jbowler Yeah, sorry for that

As for your solution, I wasn't able to check it - for some reason I wasn't able to reproduce this problem (maybe I do something different, or maybe an update in my tools or in repository fixed an issue)

So, I can nor confirm nor decline this solution, and don't even know if issue persists ._.

[jbowler]

@ctruta; I suggest applying the above patch anyway. WSL uses '\n' line endings and it exists in its own very closed environment but I just proved that I can get a file with '\r\n' on OpenSUSE and anyone how uses OpenSUSE but then accesses files in the Windows environment or written from the Windows environment will end up seeing mix'n'match line endings.

I also checked the OpenSUSE cc - it doesn't care about line endings. Nothing that reads source files should. Since it's easy to make it so with awk it should be done.