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

[Daniel Richard G.]

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

It's only intractable if your compiler doesn't support the -I option.

> 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.

That's the way most projects do it, after all.

> 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.

Modifying anything in the source directory is a non-starter, because it
could very well be read-only (as on a read-only NFS mount or the like).

> 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.

It's only important if one can't be bothered to set their #include paths
correctly.

> 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.

What problem? My patch also modifies the makefile to use an #include path of
"-I. -I$(srcdir)". People who compile software from source generally know
how these things work.

> 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) $? $@

Mark, two days ago: "zconf.h has to remain for systems that need to simply
compile the source code without using build scripts."


--Daniel