[Zlib-devel] [PATCH] Out-of-srcdir builds, -Werror resistance

[jbowler at acm.org]

I think you are trying to address a problem that is intractable without either compiler or build system support.

I reached the same conclusion with libpng, which has the identical issue in current versions because it now uses a machine-generated configuration file.

In the end libpng ended up with your first solution; the configuration file (pnglibconf.h) is not distributed, instead the various build systems (configure, cmake, makefiles) either run an awk script to make it or copy a pre-made version from somewhere else in the distribution.

>I've re-worked the patch to work another way. In addition to zconf.h staying in the source tree, 

This is what I believe makes the problem intractable, but the simple solution for people with problems is to delete it after downloading the distribution!  (I.e. leave it in the source distribution, but those of us who find this causes problems simply delete it as the first step of the integration of a new release.)  The problem, of course, is that this results in bug reports and general annoyance, that annoyance caused libpng to use a considerably more complicated solution.

>I've left the #include"zconf.h" (rather than #include<zconf.h>) in zlib.h---the #include"" ensures that zconf.h in the same
>directory as zlib.h is always used, and I think aside from this being a useful behavior, changing such a publicly-visible
>detail may have some unforeseen consequences.

Yes, that's what "" has always meant in C includes and it is an essential piece of behavior for people doing development.  It's particularly important for core header files like zlib.h, because there is always another one somewhere else in the system.

>So instead, I did the following:
>
>* When building outside of srcdir, zlib.h is copied to builddir

Fine so far, but:

>* All #include"zlib.h" references in the source are changed to
>  #include<zlib.h> so that they pull in the copy of the header in builddir
>  instead of the original in srcdir (and in turn, zlib.h pulls in the
>  zconf.h in builddir via #include"").

I think you've just moved where the problem happens haven't you?  I believe there is still a problem, however it now happens in the source files (the source files get the system zlib.h, rather than zlib.h getting the system zconf.h.)  True, it only affects people building zlib, as opposed to system developers, and that's a different set of people, but I suspect they'll actually complain even more.

It's a really difficult problem.   I have to admit that, at this point, I believe your original solution was correct but I also agree with Mark that making zlib such that it doesn't just compile out-of-the-box is a big change.  Since zlib uses a Makefile I think that it maybe could be made to copy zconf.h and if that can be done it is a much better solution:

zconf.h: zconf.h.in
	$(CP) $? $@

That's what libpng does; it works if zconf.h has been machine-generated because then it must be more up-to-date than the previously unpacked zconf.h.in (unless you have really bad timezone problems and are really enthusiastic, but then I think you will work it out PDQ.)  It works with the GNU -I. people because the same-directory interpretation of "zlib.h" can't be satisfied (because zconf.h isn't in the same directory as zlib.h) and it works with both the other approaches I know about (original ARM Norcroft -j which adds search directories for "" and the SUN(deceased) solution which used transparent mounts and just works anyway regardless (NSE?).)

John Bowler <jbowler at acm.org>