On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski <j...@jagunet.com> wrote:
> I'm sorry but I'm confused. The patch is as specific as you can get. It > just adds the minimal option and JUST for filters and JUST if libxml2 is > part of the build. > Understood, but you might have overlooked the fact that changing CPPFLAGS (or CFLAGS - even worse) changes it for the entire build. My normal config, without your patch; ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static ./build/config_vars.mk:PICFLAGS = ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include ./build/config_vars.mk:CPPFLAGS = ./build/config_vars.mk:CFLAGS = ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security -Wunused ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread ./build/config_vars.mk:INTERNAL_CPPFLAGS = With your patch in 2.5.x; ./build/config_vars.mk:SHLTCFLAGS = -prefer-pic ./build/config_vars.mk:LTCFLAGS = -prefer-non-pic -static ./build/config_vars.mk:PICFLAGS = ./build/config_vars.mk:UNITTEST_CFLAGS = -pthread ./build/config_vars.mk:ab_CFLAGS = -I/opt/openssl111/include ./build/config_vars.mk:CPPFLAGS = ./build/config_vars.mk:CFLAGS = ./build/config_vars.mk:CFLAGS_FOR_BUILD = ./build/config_vars.mk:NOTEST_CPPFLAGS = -DAP_DEBUG ./build/config_vars.mk:NOTEST_CFLAGS = -std=c89 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -Wformat -Wformat-security -Wunused -Wno-error=comment ./build/config_vars.mk:EXTRA_CPPFLAGS = -DLINUX -D_REENTRANT -D_GNU_SOURCE ./build/config_vars.mk:EXTRA_CFLAGS = -g -O2 -pthread ./build/config_vars.mk:INTERNAL_CPPFLAGS = As you can see, you didn't modify only modules/filters/ ... Maybe you meant to modify MOD_CPPFLAGS, as modules/http2/modules.mak does? > Anything else seems more disruptive than that. So why are the more > disruptive changes preferred? I'm just trying to understand the logic there. > My thought is that your observation was spot-on that libxml2, but soon more and more system headers will introduce C99 headers, and there is no reason to apply just the bandaid, certainly not to the whole server based on accumulated individual modules/foo/config.m4 bandaids. That's my objection to the commit in trunk. If we agree this is a problem to solve, let's not presume libxml2 will be the end of it, and produce another tarball that gets broken with maintainer mode in the next OS release of your favorite *nix? I'm seeing it as inevitable that we should allow all manner of c99'isms from system headers when we build in our most strict mode, but when we don't build in maintainer-mode, to leave things at c89 without -Wall etc. I see that as the most flexible compromise, without suggesting that we *add* c99'isms to httpd itself, just yet.
