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 <wr...@rowe-clan.net>
wrote:

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

On Wed, Mar 13, 2019 at 7:43 AM Jim Jagielski <j...@jagunet.com> 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!
>

Reply via email to