httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: mod_brotli in 2.4.x is missing a few Makefile changes
Date Sun, 30 Apr 2017 23:59:39 GMT
On Apr 29, 2017 9:19 PM, "Gregg Smith" <gls@gknw.net> wrote:


On 4/29/2017 5:19 PM, Gregg Smith wrote:

Bill, viewing the complete thread your reasoning here should have
> precluded this discussion years ago when pcre went to cmake, so at or
> before 2.4.0. After all, it's the only way to build pcre which is a hard
> requirement, not soft like brotli.
>
>
I guess I didn't see it all. I see now where your reasoning is as far as
doing it now and not before.


I am not clear either; I'm putting forward a rationale for simplifying our
repository in 2.5.x+++ and not actually suggesting we remove any module.

If we add modules to 2.4.x in subversion releases, and a given module
requires CMake, my comment was that it's possible for us to consider
supporting this only under cmake and not under the dsw/dsp build schema.

I see no majority as 3 do, 3 do not (if I include expat). This is assuming
nghttp2 fixed the cmake problem I had on windows. I would think so as a
long time and many versions have come since then.

I'm still against removal/shorting legacy yet not against recommending
cmake.


Again my comments are largely about what comes next. At the time 2.4.0 was
prepared, there were a number of archaic pcre options. That won't be the
case when 2.5.0 beta is tagged. I've always been against breaking changes
during subversion point bumps, and lessening the dsw/dsp/mak support would
be one such change if it happened in any 2.4.x release. Because there is no
mod_,brotli in 2.4.25, including or excluding it from one schema or another
is not a breaking change by any measure.

There is one and only one justification for the unsupported dsw/dsp format
and that is simply that MS broke the ability to export .mak files when
introducing VcProj/sln solutions.

I will support, if a majority (or significant minority) insists on VcProj
files within an sln that cannot be correctly generated under CMake. I
refuse to persist with dsp/dsw files because CMake can emit these on its
own.

There is no surviving supported tool that speaks dsw/dsp and such files
must go away as we roll out a new 2.5.x for consideration.

Mime
View raw message