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. Anything else seems more disruptive than that. So why are the more 
disruptive changes preferred? I'm just trying to understand the logic there.

> On Jan 16, 2019, at 4:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> In case my opinion wasn't clear, I'm +1 to any of the proposed choices,
> but I'm also partial to choice 2 or 1, at least add -Wno-error=comment
> in maintainer mode, or simply switch to -std=c99 presuming that more 
> and more of the system headers follow c99 syntax over time. 
> And revert the tweak of modules/filters/config.m4.
> 
> On Wed, Jan 16, 2019 at 3:39 AM Plüm, Rüdiger, Vodafone Group 
> <ruediger.pl...@vodafone.com <mailto:ruediger.pl...@vodafone.com>> wrote:
> 
> C2 General
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Stefan Eissing <stefan.eiss...@greenbytes.de 
> > <mailto:stefan.eiss...@greenbytes.de>>
> > Gesendet: Mittwoch, 16. Januar 2019 10:00
> > An: dev@httpd.apache.org <mailto:dev@httpd.apache.org>
> > Betreff: Re: svn commit: r1850745 -
> > /httpd/httpd/trunk/modules/filters/config.m4
> > 
> > 
> > 
> > > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr <wrowe@rowe-
> > clan.net <http://clan.net/>>:
> > >
> > > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski <j...@jagunet.com 
> > > <mailto:j...@jagunet.com>> wrote:
> > >
> > > > On Jan 15, 2019, at 9:21 AM, Eric Covener <cove...@gmail.com 
> > > > <mailto:cove...@gmail.com>> wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski <j...@jagunet.com 
> > > > <mailto:j...@jagunet.com>>
> > wrote:
> > > >>
> > > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr <wr...@rowe-clan.net 
> > > >> <mailto:wr...@rowe-clan.net>>
> > wrote:
> > > >>
> > > >> Hi Jim,
> > > >>
> > > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> > building on the Fedora 29, largely frozen end-of-july. Reverting the
> > patch below and toggling -std=c89 to -std=c99 in configure.in 
> > <http://configure.in/> building
> > all but two modules from trunk is building clean, and results in this
> > command for error checking;
> > > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
> > pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> > -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
> > Wformat -Wformat-security -Wunused     -DLINUX -D_REENTRANT -
> > D_GNU_SOURCE -DAP_DEBUG
> > > >>
> > > >> Is it reasonable to enforce c99 limitations at this late date? I'm
> > not suggesting we change the general builds from c89 in the 2.4 branch,
> > but that is something we might want to consider for trunk, 20 years out.
> > > >>
> > > >>
> > > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
> > considering that we are in 2019 already :)
> > > >>
> > > >> Any platform that lacks a c99 compatible CC likely doesn't build
> > anyway.
> > > >
> > > > As a binary distributor, even though a C99 compiler may be available
> > > > on platform X, it might not be in use.  Wouldn't love seeing it in
> > > > 2.4.
> > >
> > > I'm not proposing a change for 2.4... but I wouldn't oppose it either
> > :)
> > >
> > > Allowing c99 for trunk would make backporting to 2.4 (which would stay
> > c89) possibly more difficult. This is either a good thing or a bad
> > thing. So far, however, iirc we have not had any issues sticking with
> > c89 and I don't think the above would warrant such a change. IMO of
> > course.
> > >
> > > I might not have been clear, above. I'm not suggesting changing things
> > for the
> > > customary build, leave that (at least on httpd 2.4) as -std=c89. I
> > think we should
> > > have this discussion of when we will begin accepting c99 source
> > patches, but
> > > that isn't the immediate problem you've tripped over.
> > >
> > > I see several options;
> > >
> > >   Only for maintainer mode, where we are strictly handling all errors,
> > always
> > >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
> > may arise.)
> > >   All the system headers using c99 (or earlier) semantics should
> > behave well.
> > >
> > >   Or, for maintainer mode, always relax the comments restriction only
> > so we
> > >   have -std=c89 -Werror -Wall -Wno-error=comment (but not modified in
> > the
> > >   modules/filters/config.m4 where it isn't apparent who toggled this.)
> > You can
> > >   almost call this c99-lite which solves one c99'ism in newer system
> > headers
> > >   without allowing all the c99'isms in system headers.
> > >
> > >   Or, staying closest to the proposed patch, add -Wno-error=comment
> > only
> > >   to mod_proxy_html's CPPFLAGS, and stop messing with the rest of the
> > >   compilation for a single module.
> > >
> > > In every case, I'm expecting we still adhere to c89, especially in
> > httpd-2.4
> > > branch. A typical compilation (non-maintainer-mode) should catch most
> > > of those irregularities.
> > 
> > My pov:
> > - as long as 2.4.x is our only release branch, I'd like trunk maintainer
> > mode to stay compatible
> > - I would like to switch to c99 as soon as 2.6.0 is out
> > - The CPPFLAGS switch for the module only seems to be the least
> > intrusive
> 
> Sounds sensible.
> 
> Regards
> 
> Rüdiger

Reply via email to