Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <19c4aba2-6c3e-ffcd-799c-7a13c888ff8d@gknw.net>
References: <CAKQ1sVNULCGse0rdCjd64APFATLX5gTWOZKtHjw_zTMu-acL9w@mail.gmail.com>
 <60c3f5d5-8e7e-19b0-4641-cdace2d6cb4f@gknw.net> <5e1b0bac-3a61-50a0-9c84-2890b3776cba@gknw.net>
 <aos5gcprm852j2ujoag4du2pskogmrr94u@4ax.com> <CACsi252cNmc4FQ01qGhP7+deg1YYudgqNOsgUatmA06EdMOSrw@mail.gmail.com>
 <CACsi2507hVUDSA2JgZg5M90qhma=pma9w7DeMfXs5vbg-Ruwhw@mail.gmail.com>
 <mbm6gcllv5bcmhc6c1222dhgein8b8c34c@4ax.com> <CACsi253fVm6tES_ZN7aDvvuZh0BMPJoT-11=HfSmFYmq+k+2mg@mail.gmail.com>
 <djq6gcdo5ho6rje5b3t540rvkidd7qli8k@4ax.com> <86af4ae8-ba0a-0c62-46eb-86f68f43e0fc@gknw.net>
 <19c4aba2-6c3e-ffcd-799c-7a13c888ff8d@gknw.net>
From: William A Rowe Jr <wrowe@rowe-clan.net>
Date: Sun, 30 Apr 2017 18:59:39 -0500
Message-ID: <CACsi251mYSyb0HZG2v8fFt_t+aHxZ4fUjUjjegD70F289RYcyg@mail.gmail.com>
Subject: Re: mod_brotli in 2.4.x is missing a few Makefile changes
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a113f6668829b05054e6b19af
archived-at: Sun, 30 Apr 2017 23:59:46 -0000

--001a113f6668829b05054e6b19af
Content-Type: text/plain; charset=UTF-8

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.

--001a113f6668829b05054e6b19af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On Apr 29, 2017 9:19 PM, &quot;Gregg Smith&quot; &lt;<a href=3D"mailto:gl=
s@gknw.net">gls@gknw.net</a>&gt; wrote:<blockquote class=3D"quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=
=3D"quoted-text">
<br>
On 4/29/2017 5:19 PM, Gregg Smith wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Bill, viewing the complete thread your reasoning here should have<br>
precluded this discussion years ago when pcre went to cmake, so at or<br>
before 2.4.0. After all, it&#39;s the only way to build pcre which is a har=
d<br>
requirement, not soft like brotli.<br>
<br>
</blockquote>
<br></div>
I guess I didn&#39;t see it all. I see now where your reasoning is as far a=
s doing it now and not before.<br></blockquote></div></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I am not clear either; I&#39;m puttin=
g forward a rationale for simplifying our repository in 2.5.x+++ and not ac=
tually suggesting we remove any module.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">If we add modules to 2.4.x in subversion releases, and a gi=
ven module requires CMake, my comment was that it&#39;s possible for us to =
consider supporting this only under cmake and not under the dsw/dsp build s=
chema.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 lon=
g time and many versions have come since then.<br>
<br>
I&#39;m still against removal/shorting legacy yet not against recommending =
cmake.<br>
</blockquote></div><br></div><div class=3D"gmail_extra" dir=3D"auto">Again =
my comments are largely about what comes next. At the time 2.4.0 was prepar=
ed, there were a number of archaic pcre options. That won&#39;t be the case=
 when 2.5.0 beta is tagged. I&#39;ve always been against breaking changes d=
uring subversion point bumps, and lessening the dsw/dsp/mak support would b=
e 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.</div><div class=3D"gmail_extra" d=
ir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">There is one =
and only one justification for the unsupported dsw/dsp format and that is s=
imply that MS broke the ability to export .mak files when introducing VcPro=
j/sln solutions.</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><di=
v class=3D"gmail_extra" dir=3D"auto">I will support, if a majority (or sign=
ificant minority) insists on VcProj files within an sln that cannot be corr=
ectly generated under CMake. I refuse to persist with dsp/dsw files because=
 CMake can emit these on its own.</div><div class=3D"gmail_extra" dir=3D"au=
to"><br></div><div class=3D"gmail_extra" dir=3D"auto">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.</div></div></div>

--001a113f6668829b05054e6b19af--