Just as a reminder of what r1850745 actually did, from an old discussion; On Wed, Jan 16, 2019 at 5:09 PM William A Rowe Jr <[email protected]> wrote:
> On Wed, Jan 16, 2019 at 3:54 PM Jim Jagielski <[email protected]> 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. > On Wed, Mar 13, 2019 at 7:43 AM Jim Jagielski <[email protected]> wrote: > Is there anyone else building 2.4 on macOS under maintainer-mode > who is also being affected by the above? The fact that I seem to > be the anyone "complaining" :) seems weird... > > Thx! >
