add inclusion protection

[Vollstrecker]

The change you asked for.

[irwir]

@madler
All looks green, still the <> form should never be in the library.

The reason is not implementation defined nature - it would be never known what header was included.
For example, this file was found in Catalina: /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/zconf.h
Angle bracket were redirecting to this file; needless to say, the preprocessed code was quite different.

[madler]

5a82f71

[madler]

Looks good. Thanks!

[madler]

@madler All looks green, still the <> form should never be in the library.

Yep. It didn't take long for an issue to pop up because of it. #1048
Resolved now.

[Vollstrecker]

I'm not sure about that one as even when a zconf.h from /usr/include was used it was adjusted to the system. I'm on Debian with installed zlib-dev and it worked. The error looks like the ones we got when the zconf in the source-tree was used so my guess is that they are using add_subdirectory in a not intended way. But as the compiler command was missing and I'm not going to investigate their code, we'll never know.

Back to topic, the savest way to get this (if there are still problems) to change to "zconf_path/zconf.h" and throwing the right locating in there from commandline.

[irwir]

I'm not sure about that one as even when a zconf.h from /usr/include was used it was adjusted to the system.

An unknown file named zconf.h might never belongs to zlib library.
Or be from a wrong version of the library.
Angle brackets should not exist even in conditional compilation.

[Vollstrecker]

We'll nver know, as you just told us the file exists and looks strange. For me that looks like someone thinks it's a good idea to ship third-party stuff, like in Visual Studio where they bundle ninja (beside cmake).

If you ever come with a solution that works (as the defaults in zconf.h don't do that everywhere) and doesn't pollute the source-treem I'm open for everything, but I doubt that.