Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

On Apr 30, 2017 12:27 PM, "Jan Ehrhardt"  wrote:

Gregg Smith in gmane.comp.apache.devel (Sun, 30 Apr 2017 08:54:34
-0700):
>On 4/30/2017 5:36 AM, Jan Ehrhardt wrote:
>
>> The problem with CMake is that it does not build all things, that AL and
>> AH put in their distributions. CMake will build Apr 1.6 and Apr-util
>> 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go.
>
>Yes Jan I realize this but "recommend" does not mean "you must."

No, but the point is that you cannot rely on CMake alone, if you want
iconv support. You must use the dsp's or the msvc makefiles.


As much as I hated the idea of persisting apr-iconv over the BSD Citrus
sources, I've found no time to port those to Windows. Better we fix this
gap of CMake support and release another 1.2.x apr-iconv in the interim.
Will look at this Monday.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

On Apr 29, 2017 9:19 PM, "Gregg Smith"  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.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

Gregg Smith in gmane.comp.apache.devel (Sun, 30 Apr 2017 08:54:34
-0700):
>On 4/30/2017 5:36 AM, Jan Ehrhardt wrote:
>
>> The problem with CMake is that it does not build all things, that AL and
>> AH put in their distributions. CMake will build Apr 1.6 and Apr-util
>> 1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go.
>
>Yes Jan I realize this but "recommend" does not mean "you must."

No, but the point is that you cannot rely on CMake alone, if you want
iconv support. You must use the dsp's or the msvc makefiles.
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/30/2017 5:36 AM, Jan Ehrhardt wrote:


The problem with CMake is that it does not build all things, that AL and
AH put in their distributions. CMake will build Apr 1.6 and Apr-util
1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go.



Yes Jan I realize this but "recommend" does not mean "you must."

The http project has recommended people use 2.4.x since it came out. We 
did not force people from using 2.2.x did we?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

Jan Ehrhardt in gmane.comp.apache.devel (Sun, 30 Apr 2017 14:36:57
+0200):
>*.mak files in apr-util + the Makefile.win's in apr-util\(ces|css)

*.mak files in apr-iconv + the Makefile.win's in apr-iconv\(ces|css)

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

Gregg Smith in gmane.comp.apache.devel (Sat, 29 Apr 2017 17:19:03
-0700):
>I have no problem with "recommending" folks use cmake, none at all. I 
>find it to be a pain in the backside but that's just me. Others may 
>share this but I will not stand in the way of simply "recommending" it. 
>I'm actually for it so there are less folks new to building httpd having 
>problems because of all the quirks the different VC versions have.

The problem with CMake is that it does not build all things, that AL and
AH put in their distributions. CMake will build Apr 1.6 and Apr-util
1.6, including apr_crypto_openssl-1.dll (1.0.2 or 1.1.0) in one go.

CMake will also build the Apache binaries in another go, but nothing of
Apr-iconv. So apriconv-1.lib, libapriconv-1.lib/dll and all of the 200+
so-files in apache24\bin\iconv will not be built by CMake.
You will have to use Apache.dsw or srclib\apr-util\aprutil.dsw or the
*.mak files in apr-util + the Makefile.win's in apr-util\(ces|css) to
build the iconv binaries.
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

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

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/28/2017 9:35 AM, Jan Ehrhardt wrote:

William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
-0500):

You might have missed my thought here... suggesting that the CMake
not-so-experimental build become recommended for users who want to
build all the modules in one go including the new mod_brotli.


People like Steffen, Gregg and me disagree with you on making CMake the
only way for building Apache and all the modules in one go.


Maybe we have an English->Dutch translation error?

I have no problem with "recommending" folks use cmake, none at all. I 
find it to be a pain in the backside but that's just me. Others may 
share this but I will not stand in the way of simply "recommending" it. 
I'm actually for it so there are less folks new to building httpd having 
problems because of all the quirks the different VC versions have.


I do however have a problem with any thought or discussion of removing 
or shorting modules in the legacy build up until such time as it really 
is impossible to build with it or simply goes stale because of lack of 
will to keep it up to date which as of now has not yet happened.


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.





It sounds like you attempted to export mod_brotli.dsp to a vcproj all
on it's own which has never been possible.


It is perfectly possible. That is how I added mod_fcgid and now
mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or
vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an
existing project to Apache.sln. I am doing the same thing when mod_http2
changes the headers or sources.

For 2.4.next I will convert Apache.dsw once again and add mod_fcgid
afterwards.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

On Apr 28, 2017 2:40 PM, "Steffen"  wrote:

cvtdsp.pl is not a hassle, just a easy step.

Quote:  you should not need cvtdsp.pl -2005 with VC14. They fixed this in
the conversion.


Terrific, this is verified?!?

Otherwise there is no requirement for a Windows build to have an installed
Perl, which is as if not more heavy-weight dependency than cmake.

You mentioned majority.
Nope:  a majority now provide a cmake option.

Bottom line is that I and quite some fellows are sticking with the
GUI/dsw/dsp/mak. Oh so easy in all aspects for me as non unix user.


And cmake will give you DSW/DSP, or SLN/VcProj, or... So what is your
complaint to perpetuate a legacy unsupported(*) commercial standard by the
entire project when an open and cross platform alternative exists which is
modifible and maintainable by all committers exists and is required
ultimately to have a binary build at all?

I encourage all to use what they are most comfortable with, whether is is
DSW/DSP on Studio 6, or the most recent project format of Studio 2017, or
plain old .mak files.

As The Designer, the Windows build was crafted to require as few specific
additional tools as possible, and if required, keep them small and easy to
procure. Awk (vs Perl) is one example.

When cmake wasn't needed by one of our dependencies in the past, requiring
cmake seemed excessive. With the transition of PCRE and likely soon others,
leveraging cmake becomes dirt simple obvious.

We don't devolve here to proposal A sucks, B rules; we have reasoned
technical discussions on the merits of proposal A vs B. I need your
technical argument against adopting cmake before we can finish this
reasoned argument.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Steffen]

cvtdsp.pl is not a hassle, just a easy step. 

Quote:  you should not need cvtdsp.pl -2005 with VC14. They fixed this in the 
conversion.

You mentioned majority. 
Nope:  a majority now provide a cmake option.

Bottom line is that I and quite some fellows are sticking with the 
GUI/dsw/dsp/mak. Oh so easy in all aspects for me as non unix user. 

> Op 28 apr. 2017 om 19:43 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
> It's not a question of majority - a majority now provide a cmake option.
> 
> It is a question of dependency, PCRE must be built, PCRE must be
> configured with cmake, cmake is a mandatory tool for configuring httpd
> on windows, irrespective of how many times it must be invoked. brotli
> is a new nice-to-have and offers three different build solutions.
> 
> If invoked for httpd, the resulting *build* may be Microsoft Solution Files,
> Microsoft MSBuild Files, Microsoft NMake files and even others. It can
> emit .dsp files, not that anyone would want that today :)
> 
> So arguing that utilizing cmake 'removes the studio files' misses the point.
> They aren't lost, they are easily created without the hassles of cvtdsp.pl
> and in a manner that can be maintained and tested by even the Unix-only
> contributors.
> 
> 
>> On Fri, Apr 28, 2017 at 12:11 PM, Steffen  wrote:
>> Accurate:  I only/must use cmake with pcre and brotli, rest/most  is make.  
>> No cmake *majority*.
>> 
 Op 28 apr. 2017 om 18:45 heeft William A Rowe Jr  het 
 volgende geschreven:
 
 On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt  wrote:
 William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
 -0500):
> You might have missed my thought here... suggesting that the CMake
> not-so-experimental build become recommended for users who want to
> build all the modules in one go including the new mod_brotli.
 
 People like Steffen, Gregg and me disagree with you on making CMake the
 only way for building Apache and all the modules in one go.
>>> 
>>> And until brotli (topic of current discussion) it was convenient to hide 
>>> behind
>>> the fact that CMake wasn't necessary. Now that the *majority* of httpd 
>>> project
>>> dependencies must all be configured using cmake (and build with one of a
>>> number of actual toolchains, including your favored Visual Studio GUI view,
>>> msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling
>>> reason to ship .mak + .dsp has now evaporated.
>>> 
>>> I will never invoke devenv.exe "target" from the CMake output, I like the
>>> simpler forms better, but I'm happy to help diagnose anything that CMake
>>> is doing wrong in emitting the vcproj or makefile output for your 
>>> consumption.
>>> 
>>> The lack of understanding of why these libs exist in the .mak and not in the
>>> .dep files Gregg updated illustrates that the old .dsp files are no longer 
>>> of
>>> any substantive value. As I mentioned earlier, I haven't used the .dsw or
>>> these resulting .mak files in a decade because my httpd.exe+++ build all
>>> seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the
>>> final install prefix for httpd), and I can fix everything by munging INCLUDE
>>> and LIB envvars vs. a nightmare of unpacking sources into directories of
>>> different names than their source distribution, keeping up with build tree
>>> restructuring by the maintainers, or munging .dsp/.mak files.
>> 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

It's not a question of majority - a majority now provide a cmake option.

It is a question of dependency, PCRE must be built, PCRE must be
configured with cmake, cmake is a mandatory tool for configuring httpd
on windows, irrespective of how many times it must be invoked. brotli
is a new nice-to-have and offers three different build solutions.

If invoked for httpd, the resulting *build* may be Microsoft Solution Files,
Microsoft MSBuild Files, Microsoft NMake files and even others. It can
emit .dsp files, not that anyone would want that today :)

So arguing that utilizing cmake 'removes the studio files' misses the point.
They aren't lost, they are easily created without the hassles of cvtdsp.pl
and in a manner that can be maintained and tested by even the Unix-only
contributors.


On Fri, Apr 28, 2017 at 12:11 PM, Steffen  wrote:
> Accurate:  I only/must use cmake with pcre and brotli, rest/most  is make.  
> No cmake *majority*.
>
>> Op 28 apr. 2017 om 18:45 heeft William A Rowe Jr  het 
>> volgende geschreven:
>>
>>> On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt  wrote:
>>> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
>>> -0500):
 You might have missed my thought here... suggesting that the CMake
 not-so-experimental build become recommended for users who want to
 build all the modules in one go including the new mod_brotli.
>>>
>>> People like Steffen, Gregg and me disagree with you on making CMake the
>>> only way for building Apache and all the modules in one go.
>>
>> And until brotli (topic of current discussion) it was convenient to hide 
>> behind
>> the fact that CMake wasn't necessary. Now that the *majority* of httpd 
>> project
>> dependencies must all be configured using cmake (and build with one of a
>> number of actual toolchains, including your favored Visual Studio GUI view,
>> msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling
>> reason to ship .mak + .dsp has now evaporated.
>>
>> I will never invoke devenv.exe "target" from the CMake output, I like the
>> simpler forms better, but I'm happy to help diagnose anything that CMake
>> is doing wrong in emitting the vcproj or makefile output for your 
>> consumption.
>>
>> The lack of understanding of why these libs exist in the .mak and not in the
>> .dep files Gregg updated illustrates that the old .dsp files are no longer of
>> any substantive value. As I mentioned earlier, I haven't used the .dsw or
>> these resulting .mak files in a decade because my httpd.exe+++ build all
>> seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the
>> final install prefix for httpd), and I can fix everything by munging INCLUDE
>> and LIB envvars vs. a nightmare of unpacking sources into directories of
>> different names than their source distribution, keeping up with build tree
>> restructuring by the maintainers, or munging .dsp/.mak files.
>

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Steffen]

Accurate:  I only/must use cmake with pcre and brotli, rest/most  is make.  No 
cmake *majority*. 

> Op 28 apr. 2017 om 18:45 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
>> On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt  wrote:
>> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
>> -0500):
>>> You might have missed my thought here... suggesting that the CMake
>>> not-so-experimental build become recommended for users who want to
>>> build all the modules in one go including the new mod_brotli.
>> 
>> People like Steffen, Gregg and me disagree with you on making CMake the
>> only way for building Apache and all the modules in one go.
> 
> And until brotli (topic of current discussion) it was convenient to hide 
> behind
> the fact that CMake wasn't necessary. Now that the *majority* of httpd project
> dependencies must all be configured using cmake (and build with one of a
> number of actual toolchains, including your favored Visual Studio GUI view,
> msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling
> reason to ship .mak + .dsp has now evaporated.
> 
> I will never invoke devenv.exe "target" from the CMake output, I like the
> simpler forms better, but I'm happy to help diagnose anything that CMake
> is doing wrong in emitting the vcproj or makefile output for your consumption.
> 
> The lack of understanding of why these libs exist in the .mak and not in the
> .dep files Gregg updated illustrates that the old .dsp files are no longer of
> any substantive value. As I mentioned earlier, I haven't used the .dsw or
> these resulting .mak files in a decade because my httpd.exe+++ build all
> seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the
> final install prefix for httpd), and I can fix everything by munging INCLUDE
> and LIB envvars vs. a nightmare of unpacking sources into directories of
> different names than their source distribution, keeping up with build tree
> restructuring by the maintainers, or munging .dsp/.mak files.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

On Fri, Apr 28, 2017 at 11:35 AM, Jan Ehrhardt  wrote:
> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
> -0500):
>>You might have missed my thought here... suggesting that the CMake
>>not-so-experimental build become recommended for users who want to
>>build all the modules in one go including the new mod_brotli.
>
> People like Steffen, Gregg and me disagree with you on making CMake the
> only way for building Apache and all the modules in one go.

And until brotli (topic of current discussion) it was convenient to hide behind
the fact that CMake wasn't necessary. Now that the *majority* of httpd project
dependencies must all be configured using cmake (and build with one of a
number of actual toolchains, including your favored Visual Studio GUI view,
msbuild, nmake makefiles, even eclipse etc etc etc.) the most compelling
reason to ship .mak + .dsp has now evaporated.

I will never invoke devenv.exe "target" from the CMake output, I like the
simpler forms better, but I'm happy to help diagnose anything that CMake
is doing wrong in emitting the vcproj or makefile output for your consumption.

The lack of understanding of why these libs exist in the .mak and not in the
.dep files Gregg updated illustrates that the old .dsp files are no longer of
any substantive value. As I mentioned earlier, I haven't used the .dsw or
these resulting .mak files in a decade because my httpd.exe+++ build all
seeks an installed tree expat/pcre/apr/openssl/libxml2/zlib (ultimately, the
final install prefix for httpd), and I can fix everything by munging INCLUDE
and LIB envvars vs. a nightmare of unpacking sources into directories of
different names than their source distribution, keeping up with build tree
restructuring by the maintainers, or munging .dsp/.mak files.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 10:30:03
-0500):
>You might have missed my thought here... suggesting that the CMake
>not-so-experimental build become recommended for users who want to
>build all the modules in one go including the new mod_brotli.

People like Steffen, Gregg and me disagree with you on making CMake the
only way for building Apache and all the modules in one go.

>It sounds like you attempted to export mod_brotli.dsp to a vcproj all
>on it's own which has never been possible.

It is perfectly possible. That is how I added mod_fcgid and now
mod_brotli to my existing Apache 2.4.25 sln. Convert to vcproj (VC9) or
vcxproj (VC11/VC14), add the x64 configuration, add the vc(x)proj as an
existing project to Apache.sln. I am doing the same thing when mod_http2
changes the headers or sources.

For 2.4.next I will convert Apache.dsw once again and add mod_fcgid
afterwards.
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jacob Champion]

On 04/28/2017 08:08 AM, Steffen wrote:

Cmake is a way to go.  IDE building is the preferred way to go, all the
vs goodies then available. And easy to maintain dsw and dsp etc.


Does CMake not provide the nice IDE goodies on your machine? I'm quite 
happy with it for mod_websocket, and not at all happy with the dsw/dsp, 
which I've never gotten to upconvert correctly to the latest VS version.


--Jacob

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

On Fri, Apr 28, 2017 at 10:05 AM, Jan Ehrhardt  wrote:
> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53
> -0500):
>>Hmmm...
>>
>>Building brotli libs requires CMake.
>>
>>Perhaps only support building mod_brotli through the CMake build, and not
>>the legacy build?
>
> That would be not very convenient if you want to build Apache with all
> modules in one go.

You might have missed my thought here... suggesting that the CMake
not-so-experimental build become recommended for users who want to
build all the modules in one go including the new mod_brotli.

It sounds like you attempted to export mod_brotli.dsp to a vcproj all
on it's own which has never been possible. If you loaded Apache[2].dsw
and allowed it convert *all* the modules, mod_brotli.dsp should be fine.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Steffen]

Agree. 

Thanks to Gregg, dsp/dsw/makefile mod_brotli is already there in branches 
2.4.x. 

Cmake only needed to build the brotli libs. 

> Op 28 apr. 2017 om 17:05 heeft Jan Ehrhardt  het volgende 
> geschreven:
> 
> William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53
> -0500):
>> Hmmm...
>> 
>> Building brotli libs requires CMake.
>> 
>> Perhaps only support building mod_brotli through the CMake build, and not
>> the legacy build?
> 
> That would be not very convenient if you want to build Apache with all
> modules in one go.
> -- 
> Jan
> 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Steffen]

This is a trigger again for the old repeating discussion. 

Cmake is a way to go.  IDE building is the preferred way to go, all the vs 
goodies then available. And easy to maintain dsw and dsp etc. 

> Op 28 apr. 2017 om 16:55 heeft William A Rowe Jr  het 
> volgende geschreven:
> 
> Jan,
> 
> That is correct. The .dsp is wired to interrelated projects via the .dsw 
> file.  Exporting the projects into .mak files causes all the 'depends upon' 
> libs to be added. See any other such as mod_status. If we were building 
> brotli in-tree you would add the libbrotli .dsp and it would resolve that lib.
> 
> Which is why my product build (not /dist/httpd/ win32 binary) differed for a 
> decade+... My clone of Apache.dsw has no apr, therefore I used the cvtdsp.pl 
> logic to put in all the required libapr-1.lib dependencies. A real PITA.
> 
> They simply go away after httpd-2.4.x as no longer supported. CMake just 
> works and eliminates a ton of ASF and external maintenance.
> 
> 
> 
>> On Apr 28, 2017 9:19 AM, "Jan Ehrhardt"  wrote:
>> Hi Gregg,
>> 
>> Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50
>> -0700):
>> >Actually, I'll test here in a while and commit tomorrow.
>> 
>> Quote from modules/filters/mod_brotli.dsp
>> 
>> > +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo 
>> > /subsystem:windows /dll /incremental:no /debug 
>> > /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" 
>> > /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref
>> 
>> The dsp seems to be missing a reference to libapr-1.lib,
>> libaprutil-1.lib and libhttpd.lib, which is present in the
>> mod_brotli.mak:
>> 
>> +LINK32=link.exe
>> +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo
>> /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb"
>> /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so"
>> /implib:"$(OUTDIR)\mod_brotli.lib"
>> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref
>> +LINK32_OBJS= \
>> +   "$(INTDIR)\mod_brotli.obj" \
>> +   "$(INTDIR)\mod_brotli.res" \
>> +   "..\..\srclib\apr\Release\libapr-1.lib" \
>> +   "..\..\srclib\apr-util\Release\libaprutil-1.lib" \
>> +   "..\..\Release\libhttpd.lib"
>> 
>> When I converted the dsp to mod_brotli.vcxproj it did not compile
>> because of missing symbols like __imp__apr_bucket* or something like
>> that..
>> --
>> Jan
>> 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

William A Rowe Jr in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:57:53
-0500):
>Hmmm...
>
>Building brotli libs requires CMake.
>
>Perhaps only support building mod_brotli through the CMake build, and not
>the legacy build?

That would be not very convenient if you want to build Apache with all
modules in one go.
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jim Jagielski]

OK, thx for clearing that up.

Cheers!
> On Apr 28, 2017, at 9:50 AM, Jan Ehrhardt  wrote:
> 
> Jim Jagielski in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:29:01
> -0400):
>> Are these issues with *building* the brotli library during
>> the configure/make of httpd?
> 
> No, building the brotli library itself is a CMake thing. Something like
> 
> CMake -G "Visual Studio 14 2015 Win64" -DBUILD_SHARED_LIBS=OFF .
> msbuild brotli.sln /P:Configuration=MinSizeRel
> 
>> Why, exactly, are we doing this if this is, in fact, what
>> we are doing? Just curious why we are taking this dependency
>> on directly.
> 
> The dependency on libapr-1.lib, libaprutil-1.lib and libhttpd.lib
> (besides brotlicommon.lib and brotlienc.lib) is when building
> mod_brotli.so.
> -- 
> Jan
> 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

Hmmm...

Building brotli libs requires CMake.

Perhaps only support building mod_brotli through the CMake build, and not
the legacy build?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[William A Rowe Jr]

Jan,

That is correct. The .dsp is wired to interrelated projects via the .dsw
file.  Exporting the projects into .mak files causes all the 'depends upon'
libs to be added. See any other such as mod_status. If we were building
brotli in-tree you would add the libbrotli .dsp and it would resolve that
lib.

Which is why my product build (not /dist/httpd/ win32 binary) differed for
a decade+... My clone of Apache.dsw has no apr, therefore I used the
cvtdsp.pl logic to put in all the required libapr-1.lib dependencies. A
real PITA.

They simply go away after httpd-2.4.x as no longer supported. CMake just
works and eliminates a ton of ASF and external maintenance.



On Apr 28, 2017 9:19 AM, "Jan Ehrhardt"  wrote:

> Hi Gregg,
>
> Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50
> -0700):
> >Actually, I'll test here in a while and commit tomorrow.
>
> Quote from modules/filters/mod_brotli.dsp
>
> > +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo
> /subsystem:windows /dll /incremental:no /debug
> /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" /base:@
> ..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref
>
> The dsp seems to be missing a reference to libapr-1.lib,
> libaprutil-1.lib and libhttpd.lib, which is present in the
> mod_brotli.mak:
>
> +LINK32=link.exe
> +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo
> /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb"
> /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so"
> /implib:"$(OUTDIR)\mod_brotli.lib"
> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref
> +LINK32_OBJS= \
> +   "$(INTDIR)\mod_brotli.obj" \
> +   "$(INTDIR)\mod_brotli.res" \
> +   "..\..\srclib\apr\Release\libapr-1.lib" \
> +   "..\..\srclib\apr-util\Release\libaprutil-1.lib" \
> +   "..\..\Release\libhttpd.lib"
>
> When I converted the dsp to mod_brotli.vcxproj it did not compile
> because of missing symbols like __imp__apr_bucket* or something like
> that..
> --
> Jan
>
>

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

Jim Jagielski in gmane.comp.apache.devel (Fri, 28 Apr 2017 09:29:01
-0400):
>Are these issues with *building* the brotli library during
>the configure/make of httpd?

No, building the brotli library itself is a CMake thing. Something like

CMake -G "Visual Studio 14 2015 Win64" -DBUILD_SHARED_LIBS=OFF .
msbuild brotli.sln /P:Configuration=MinSizeRel

>Why, exactly, are we doing this if this is, in fact, what
>we are doing? Just curious why we are taking this dependency
>on directly.

The dependency on libapr-1.lib, libaprutil-1.lib and libhttpd.lib
(besides brotlicommon.lib and brotlienc.lib) is when building
mod_brotli.so.
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jim Jagielski]

This just clicked for me...

Are these issues with *building* the brotli library during
the configure/make of httpd?

Why, exactly, are we doing this if this is, in fact, what
we are doing? Just curious why we are taking this dependency
on directly.

> On Apr 28, 2017, at 9:19 AM, Jan Ehrhardt  wrote:
> 
> Hi Gregg,
> 
> Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50
> -0700):
>> Actually, I'll test here in a while and commit tomorrow.
> 
> Quote from modules/filters/mod_brotli.dsp
> 
>> +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo 
>> /subsystem:windows /dll /incremental:no /debug 
>> /out:".\Release\mod_brotli.so" /libpath:"../../srclib/brotli" 
>> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref
> 
> The dsp seems to be missing a reference to libapr-1.lib,
> libaprutil-1.lib and libhttpd.lib, which is present in the
> mod_brotli.mak:
> 
> +LINK32=link.exe
> +LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo
> /subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb"
> /libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so"
> /implib:"$(OUTDIR)\mod_brotli.lib"
> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref 
> +LINK32_OBJS= \
> + "$(INTDIR)\mod_brotli.obj" \
> + "$(INTDIR)\mod_brotli.res" \
> + "..\..\srclib\apr\Release\libapr-1.lib" \
> + "..\..\srclib\apr-util\Release\libaprutil-1.lib" \
> + "..\..\Release\libhttpd.lib"
> 
> When I converted the dsp to mod_brotli.vcxproj it did not compile
> because of missing symbols like __imp__apr_bucket* or something like
> that..
> -- 
> Jan
> 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jan Ehrhardt]

Hi Gregg,

Gregg Smith in gmane.comp.apache.devel (Tue, 25 Apr 2017 18:23:50
-0700):
>Actually, I'll test here in a while and commit tomorrow.

Quote from modules/filters/mod_brotli.dsp

> +# ADD LINK32 kernel32.lib brotlicommon.lib brotlienc.lib /nologo 
> /subsystem:windows /dll /incremental:no /debug /out:".\Release\mod_brotli.so" 
> /libpath:"../../srclib/brotli" 
> /base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref

The dsp seems to be missing a reference to libapr-1.lib,
libaprutil-1.lib and libhttpd.lib, which is present in the
mod_brotli.mak:

+LINK32=link.exe
+LINK32_FLAGS=kernel32.lib brotlicommon.lib brotlienc.lib /nologo
/subsystem:windows /dll /incremental:no /pdb:"$(OUTDIR)\mod_brotli.pdb"
/libpath="../../srclib/brotli" /debug /out:"$(OUTDIR)\mod_brotli.so"
/implib:"$(OUTDIR)\mod_brotli.lib"
/base:@..\..\os\win32\BaseAddr.ref,mod_brotli.so /opt:ref 
+LINK32_OBJS= \
+   "$(INTDIR)\mod_brotli.obj" \
+   "$(INTDIR)\mod_brotli.res" \
+   "..\..\srclib\apr\Release\libapr-1.lib" \
+   "..\..\srclib\apr-util\Release\libaprutil-1.lib" \
+   "..\..\Release\libhttpd.lib"

When I converted the dsp to mod_brotli.vcxproj it did not compile
because of missing symbols like __imp__apr_bucket* or something like
that..
-- 
Jan

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Evgeny Kotkov]

Jim Jagielski  writes:

> BTW, there are also deltas for config.m4 in modules/filters mainly
> around mod_brotli. At present what is in 2.4 seems to work fine, but
> should we consider backporting config.m4 as well?

The difference is caused by these four mentioned changes (r1761824,
r1771789, r1771827, r1779111).  With them applied, this part of the
modules/filters/config.m4 file should be identical between trunk and
2.4.x.

I proposed the whole group for the backport in r1792805 and r1792806.


Regards,
Evgeny Kotkov

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/26/2017 7:53 AM, Jim Jagielski wrote:

Thanks! Are these the full diffs for Makefile?

On Apr 26, 2017, at 10:50 AM, Gregg Smith  wrote:


On 4/26/2017 4:51 AM, Jim Jagielski wrote:



On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov  wrote:

Hi all,

I noticed that the version of mod_brotli that has been backported to 2.4.x
lacks a few Makefile changes from trunk.  This results in a failing Unix
build when mod_brotli is not being built.


Hmmm I can't recreate that here on CentOS or macOS.

Nevertheless, I know that the Makefiles were diff, but the
backport didn't include those diffs so I couldn't just apply
them after the fact, so I am +1 for adding them as a "new"
backport.


Tested both IDE and command line builds.
Commited r1792753



Yes, for the legacy build.
Includes the addition to BaseAddr.ref (which conflicts from trunk due to 
the different order in which modules have been added to 2.4).

Addition to the LoadModule section of the Windows httpd.conf.

We should be good to go all the way around.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jim Jagielski]

BTW, there are also deltas for config.m4 in modules/filters mainly
around mod_brotli. At present what is in 2.4 seems to work fine, but
should we consider backporting config.m4 as well?

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jim Jagielski]

Thanks! Are these the full diffs for Makefile?
> On Apr 26, 2017, at 10:50 AM, Gregg Smith  wrote:
> 
> 
> On 4/26/2017 4:51 AM, Jim Jagielski wrote:
>> 
>>> On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I noticed that the version of mod_brotli that has been backported to 2.4.x
>>> lacks a few Makefile changes from trunk.  This results in a failing Unix
>>> build when mod_brotli is not being built.
>> 
>> Hmmm I can't recreate that here on CentOS or macOS.
>> 
>> Nevertheless, I know that the Makefiles were diff, but the
>> backport didn't include those diffs so I couldn't just apply
>> them after the fact, so I am +1 for adding them as a "new"
>> backport.
>> 
> Tested both IDE and command line builds.
> Commited r1792753

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

On 4/26/2017 4:51 AM, Jim Jagielski wrote:



On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov  wrote:

Hi all,

I noticed that the version of mod_brotli that has been backported to 2.4.x
lacks a few Makefile changes from trunk.  This results in a failing Unix
build when mod_brotli is not being built.


Hmmm I can't recreate that here on CentOS or macOS.

Nevertheless, I know that the Makefiles were diff, but the
backport didn't include those diffs so I couldn't just apply
them after the fact, so I am +1 for adding them as a "new"
backport.


Tested both IDE and command line builds.
Commited r1792753

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Jim Jagielski]

> On Apr 25, 2017, at 4:34 PM, Evgeny Kotkov  
> wrote:
> 
> Hi all,
> 
> I noticed that the version of mod_brotli that has been backported to 2.4.x
> lacks a few Makefile changes from trunk.  This results in a failing Unix
> build when mod_brotli is not being built.

Hmmm I can't recreate that here on CentOS or macOS.

Nevertheless, I know that the Makefiles were diff, but the
backport didn't include those diffs so I couldn't just apply
them after the fact, so I am +1 for adding them as a "new"
backport.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

Actually, I'll test here in a while and commit tomorrow.


On 4/25/2017 6:20 PM, Gregg Smith wrote:

I have one, command line makefiles and all. I just haven't had time to
run a test build yet though lloking at it looks fine, but I like to test
first.


On 4/25/2017 2:07 PM, Yann Ylavic wrote:

Hi Evgeny,

On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkov
 wrote:


With the backport being in place in the 2.4.x branch, these changes
no longer
merge cleanly from trunk.  I can prepare a backport nomination for
them that
resolves the conflicts and add it to the 2.4.x STATUS.

What do you think?


+1


Regards,
Yann.

Index: Apache-apr2.dsw
===
--- Apache-apr2.dsw	(revision 1792168)
+++ Apache-apr2.dsw	(working copy)
@@ -1243,6 +1243,24 @@
 
 ###
 
+Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+Begin Project Dependency
+Project_Dep_Name libapr
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libhttpd
+End Project Dependency
+}}}
+
+###
+
 Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4>
 
 Package=<5>
Index: Apache.dsw
===
--- Apache.dsw	(revision 1792168)
+++ Apache.dsw	(working copy)
@@ -1483,6 +1483,27 @@
 
 ###
 
+Project: "mod_brotli"=.\modules\filters\mod_brotli.dsp - Package Owner=<4>
+
+Package=<5>
+{{{
+}}}
+
+Package=<4>
+{{{
+Begin Project Dependency
+Project_Dep_Name libapr
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libaprutil
+End Project Dependency
+Begin Project Dependency
+Project_Dep_Name libhttpd
+End Project Dependency
+}}}
+
+###
+
 Project: "mod_bucketeer"=.\modules\debugging\mod_bucketeer.dsp - Package Owner=<4>
 
 Package=<5>
Index: build/installwinconf.awk
===
--- build/installwinconf.awk	(revision 1792168)
+++ build/installwinconf.awk	(working copy)
@@ -116,6 +116,7 @@
   print "#LoadModule authz_owner_module modules/mod_authz_owner.so" > dstfl;
   print "LoadModule authz_user_module modules/mod_authz_user.so" > dstfl;
   print "LoadModule autoindex_module modules/mod_autoindex.so" > dstfl;
+  print "#LoadModule brotli_module modules/mod_brotli.so" > dstfl;
   print "#LoadModule buffer_module modules/mod_buffer.so" > dstfl;
   print "#LoadModule cache_module modules/mod_cache.so" > dstfl;
   print "#LoadModule cache_disk_module modules/mod_cache_disk.so" > dstfl;
Index: BuildBin.dsp
===
--- BuildBin.dsp	(revision 1792168)
+++ BuildBin.dsp	(working copy)
@@ -39,7 +39,7 @@
 # PROP Use_Debug_Libraries 0
 # PROP Output_Dir ""
 # PROP Intermediate_Dir ""
-# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy"
+# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Release _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy"
 # PROP Rebuild_Opt ""
 # PROP Target_File "\Apache2\bin\httpd.exe"
 # PROP Bsc_Name ".\Browse\httpd.bsc"
@@ -58,7 +58,7 @@
 # PROP Use_Debug_Libraries 1
 # PROP Output_Dir ""
 # PROP Intermediate_Dir ""
-# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _dummy"
+# PROP Cmd_Line "NMAKE /f makefile.win INSTDIR="\Apache2" LONG=Debug _trydb _trylua _tryxml _tryssl _tryzlib _trynghttp2 _trybrotli _dummy"
 # PROP Rebuild_Opt ""
 # PROP Target_File "\Apache2\bin\httpd.exe"
 # PROP Bsc_Name ".\Browse\httpd.bsc"
Index: Makefile.win
===
--- Makefile.win	(revision 1792168)
+++ Makefile.win	(working copy)
@@ -268,6 +268,33 @@
 
 !ENDIF
 
+!IF EXIST("srclib\brotli")
+
+_trybrotli:
+!IF $(USEMAK) == 1
+	cd modules\filters
+	$(MAKE) $(MAKEOPT) -f mod_brotli.mak CFG="mod_brotli - Win32 $(LONG)" RECURSE=0 $(CTARGET)
+	cd ..\..
+!ELSEIF $(USESLN) == 1
+	devenv $(TLP).sln /useenv $(CTARGET) $(LONG) /project mod_brotli
+!ELSE
+	@msdev $(TLP).dsw /USEENV /MAKE \
+		"mod_brotli - Win32 $(LONG)" /NORECURSE $(CTARGET)
+!ENDIF
+
+!ELSE
+# NOT EXIST("srclib\brotli")
+
+_trybrotli:
+	@echo -
+	@echo mod_brotli will not build unless brotli is built in srclib\brotli.  
+	@echo Version 1.0.0 and later available from https://github.com/google/brotli/releases
+	@echo build with:
+	@echo cmake -G "NMake Makefiles" 

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Gregg Smith]

I have one, command line makefiles and all. I just haven't had time to 
run a test build yet though lloking at it looks fine, but I like to test 
first.



On 4/25/2017 2:07 PM, Yann Ylavic wrote:

Hi Evgeny,

On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkov
 wrote:


With the backport being in place in the 2.4.x branch, these changes no longer
merge cleanly from trunk.  I can prepare a backport nomination for them that
resolves the conflicts and add it to the 2.4.x STATUS.

What do you think?


+1


Regards,
Yann.

Re: mod_brotli in 2.4.x is missing a few Makefile changes

[Yann Ylavic]

Hi Evgeny,

On Tue, Apr 25, 2017 at 10:34 PM, Evgeny Kotkov
 wrote:
>
> With the backport being in place in the 2.4.x branch, these changes no longer
> merge cleanly from trunk.  I can prepare a backport nomination for them that
> resolves the conflicts and add it to the 2.4.x STATUS.
>
> What do you think?

+1


Regards,
Yann.