You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2013/08/30 14:25:18 UTC
will anyone build httpd/apr with cmake on Windows?
I will be throwing a bit more time at the cmake effort in the short term,
starting with comparing the installed artifacts with those of existing
Windows builds and adding missing pieces to the todo lists. I might not do
much else proactively until my own use of the builds catches up and starts
to exceed what is implemented.
Please let me know if you
* are waiting for some certain feature (other than near perfection) before
you use it
* attempt to use it but are slowed down by tool requirements or bad
documentation or anything else
* attempt to use it but it fails so badly that you leave it in disgust with
no desire to report or try to fix anything
* try it and it works for you (what cmake backend, what other build
characteristics)
* etc.
Thanks!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Ben Reser <be...@reser.org>.
On 8/30/13 5:25 AM, Jeff Trawick wrote:
> I will be throwing a bit more time at the cmake effort in the short term,
> starting with comparing the installed artifacts with those of existing Windows
> builds and adding missing pieces to the todo lists. I might not do much else
> proactively until my own use of the builds catches up and starts to exceed what
> is implemented.
I'd be interested in using it, but haven't gotten around to looking at it yet.
I have a perl script that builds httpd along with a bunch of other things that
Subversion needs on Windows.
Without a doubt the biggest pain in doing so has always been httpd and its
dependencies.
The existing project file method has the following issues for me:
* Not all versions of VC have good support for converting projects from the
command line, some of them fail with cryptic errors. Fortunately VC2012
finally does this fairly well... But, the Express version won't convert at all
from the command line. This means it's almost impossible to fully script the
build.
* There are a lot of things that have to be done for fixing the existing
project files to work properly with a current tool chain on Windows. Fixing
them in the GUI isn't too hard, but it's a manual process. I'm not 100% sure
the hacks I've written to modify the files in place are really correct. The
build falls apart all over the place due to shared intermediary directories and
I've played whack-a-mole fixing it because what fails is random.
Beyond time the biggest barrier for me messing with this is that I primarily
care about release builds on Windows. I only really build Subversion on
Windows (even that is pretty sporadic) and I don't ever hack on things over
there, just simply test releases.
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Sep 2, 2013 at 8:38 AM, Mario Brandt <jb...@gmail.com> wrote:
> Hi Jeff,
>
> thanks for your effort on the windows build. You may take a look at
> https://github.com/winlibs/apache
>
Thanks for the pointer; that's a concise representation of the current
Windows build with modern tools. (Too bad about the requirement for
keyboard presses in the middle.) Also, it is a good source of hints for
building the other projects.
>
> Cheers
> Mario
>
>
> On 2 September 2013 14:31, Jeff Trawick <tr...@gmail.com> wrote:
>
>> Here's a simple build script that uses an existing OpenSSL installation
>> and builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it
>> has a number of dependencies on my own machine, but it should be relatively
>> easy to see all the configure parameters in one place.
>>
>> http://people.apache.org/~trawick/bldall.cmd.r1
>>
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Sep 2, 2013 at 8:38 AM, Mario Brandt <jb...@gmail.com> wrote:
> Hi Jeff,
>
> thanks for your effort on the windows build. You may take a look at
> https://github.com/winlibs/apache
>
Thanks for the pointer; that's a concise representation of the current
Windows build with modern tools. (Too bad about the requirement for
keyboard presses in the middle.) Also, it is a good source of hints for
building the other projects.
>
> Cheers
> Mario
>
>
> On 2 September 2013 14:31, Jeff Trawick <tr...@gmail.com> wrote:
>
>> Here's a simple build script that uses an existing OpenSSL installation
>> and builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it
>> has a number of dependencies on my own machine, but it should be relatively
>> easy to see all the configure parameters in one place.
>>
>> http://people.apache.org/~trawick/bldall.cmd.r1
>>
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Mario Brandt <jb...@gmail.com>.
Hi Jeff,
thanks for your effort on the windows build. You may take a look at
https://github.com/winlibs/apache
Cheers
Mario
On 2 September 2013 14:31, Jeff Trawick <tr...@gmail.com> wrote:
> Here's a simple build script that uses an existing OpenSSL installation
> and builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it
> has a number of dependencies on my own machine, but it should be relatively
> easy to see all the configure parameters in one place.
>
> http://people.apache.org/~trawick/bldall.cmd.r1
>
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Mario Brandt <jb...@gmail.com>.
Hi Jeff,
thanks for your effort on the windows build. You may take a look at
https://github.com/winlibs/apache
Cheers
Mario
On 2 September 2013 14:31, Jeff Trawick <tr...@gmail.com> wrote:
> Here's a simple build script that uses an existing OpenSSL installation
> and builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it
> has a number of dependencies on my own machine, but it should be relatively
> easy to see all the configure parameters in one place.
>
> http://people.apache.org/~trawick/bldall.cmd.r1
>
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
Here's a simple build script that uses an existing OpenSSL installation and
builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it has
a number of dependencies on my own machine, but it should be relatively
easy to see all the configure parameters in one place.
http://people.apache.org/~trawick/bldall.cmd.r1
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
Here's a simple build script that uses an existing OpenSSL installation and
builds pcre, zlib, libxml2, apr, apr-util, and httpd. Unfortunately it has
a number of dependencies on my own machine, but it should be relatively
easy to see all the configure parameters in one place.
http://people.apache.org/~trawick/bldall.cmd.r1
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Sep 3, 2013 at 8:35 PM, Ben Reser <be...@reser.org> wrote:
> On 9/1/13 4:50 AM, Jeff Trawick wrote:
> > *Doesn't it take more than one level of Visual Studio to get it into
> something
> > that the most recent versions will use?
>
> I don't think going through more than one version of Visual Studio helps,
> at
> least not if you're trying to build with Visual Studio 2012.
>
> Converting with Visual Studio 2010 can't be done from the command line, it
> has
> to be done in the GUI. Visual Studio 2012 can convert everything from the
> command line. I can't say that I've done anything older than that though I
> know I've had a working 2008 configuration at one point but I never
> scripted it
> so I don't remember the steps.
>
> The major problems I've seen after conversion are shared intermediary build
> directories, manifest files, and TargetName. Take a look at the
> build_httpd
> subroutine in this script for details of the hoops that have to be jumped
> through:
>
> https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl
too bad about all the httpd/apr build hacks, but still a nice example of a
high function workflow that can be implemented on top of general build
capabilities
I don't think there's much appreciation yet of the sheer practicality of
more individuals being able to implement a workflow that makes sense for
them when the basic build just works and little effort is spent hacking it
for one set of build tools or another. (That's not to say that there
shouldn't be some typical workflow implemented in a makefile/script shipped
with httpd.)
>
>
> All of these basically come down to Visual Studio behaving differently
> than in
> previous versions. The problem with the existing build system is that
> there's
> no way to correctly fix most of this. Anyone trying basically has to have
> all
> the tool chains all the way up from VC6 to test with.
>
> For all practical purposes it is impossible to build httpd on modern tool
> chains unless you spend a lot of time googling and looking for help posted
> on
> various forums. Some of these issues may be something that Windows
> developers
> are familiar with and just know how to fix off hand, but in my experiece I
> spent a ton of time trying to figure all of this out.
>
> So in my opinion the real failing of the existing system is that the same
> work
> is being done over and over and over again. Nobody can show up and say
> "Ohh
> VC2012 breaks due to this change, here's the patch" and then have the patch
> applied to the build system so that nobody else has to deal with that
> problem
> again.
>
> The benefit of CMake is that even more of that work can be done upstream by
> CMake and we don't necessarily even have to deal with all of it. There
> will
> always be some, but at least your conversion support is now being
> supported by
> someone that actually cares about it (no sorry Microsoft's support for
> conversion doesn't count).
>
> The cost of course is paid by the people who have already jumped through
> the
> hoops and expended the energy to figure out how to build with the current
> system. These people now have to figure out how to build with CMake which
> is
> an extra step for them.
>
> I suspect when all is said and done though that everyone will end up
> better off
> though.
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Ben Reser <be...@reser.org>.
On 9/1/13 4:50 AM, Jeff Trawick wrote:
> *Doesn't it take more than one level of Visual Studio to get it into something
> that the most recent versions will use?
I don't think going through more than one version of Visual Studio helps, at
least not if you're trying to build with Visual Studio 2012.
Converting with Visual Studio 2010 can't be done from the command line, it has
to be done in the GUI. Visual Studio 2012 can convert everything from the
command line. I can't say that I've done anything older than that though I
know I've had a working 2008 configuration at one point but I never scripted it
so I don't remember the steps.
The major problems I've seen after conversion are shared intermediary build
directories, manifest files, and TargetName. Take a look at the build_httpd
subroutine in this script for details of the hoops that have to be jumped through:
https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl
All of these basically come down to Visual Studio behaving differently than in
previous versions. The problem with the existing build system is that there's
no way to correctly fix most of this. Anyone trying basically has to have all
the tool chains all the way up from VC6 to test with.
For all practical purposes it is impossible to build httpd on modern tool
chains unless you spend a lot of time googling and looking for help posted on
various forums. Some of these issues may be something that Windows developers
are familiar with and just know how to fix off hand, but in my experiece I
spent a ton of time trying to figure all of this out.
So in my opinion the real failing of the existing system is that the same work
is being done over and over and over again. Nobody can show up and say "Ohh
VC2012 breaks due to this change, here's the patch" and then have the patch
applied to the build system so that nobody else has to deal with that problem
again.
The benefit of CMake is that even more of that work can be done upstream by
CMake and we don't necessarily even have to deal with all of it. There will
always be some, but at least your conversion support is now being supported by
someone that actually cares about it (no sorry Microsoft's support for
conversion doesn't count).
The cost of course is paid by the people who have already jumped through the
hoops and expended the energy to figure out how to build with the current
system. These people now have to figure out how to build with CMake which is
an extra step for them.
I suspect when all is said and done though that everyone will end up better off
though.
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Sep 1, 2013 at 3:19 PM, Tom Donovan <do...@bellatlantic.net>wrote:
> On 09/01/2013 09:55 AM, Jeff Trawick wrote:
> > On Sun, Sep 1, 2013 at 9:37 AM, Guenter Knauf <fuankg@apache.org<mailto:
> fuankg@apache.org>> wrote:
> >
> > Hi Jeff,
> > 1st of all a big thanks from me that you picked this up!
> > As you might imagine I'm on your side - means I love to have a
> full-automatic build without user
> > interaction, and a resulting buildlog text file which I can later
> parse with a script for errors
> > or success.
> > I have such working fine with the current VC build stuff + VC6, but
> that doesnt work for any
> > later VC versions ...
> > please keep up your work on this - its certainly a good alternative
> way for building the windows
> > binaries;
> > I'm currently swamped with other stuff, but once I have the time I
> will certainly start playing
> > around with the cmake stuff, and hope that I can help to improve it
> if needed.
> >
> > thanks, Gün.
> >
> >
> > Thanks for showing up :) I'm tired of taking a beating from the
> non-automated crowd :)
> >
> > But seriously, there's a lot of good information in the thread about
> expectations and approaches,
> > and even in the short term (last couple of hours) I've been motivated to
> revisit some of my initial
> > cmake implementation to get rid of a number of required settings that
> shouldn't be needed for
> > typical installations.
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
> Jeff,
>
> Let me second Guenter's thanks - you brought this whole effort much
> further than I ever could in
> such a short time. Much appreciated! I really look forward to using
> CMake for Windows builds
> instead of the crusty old Makefile.win & VC project conversion steps we
> have now.
>
> I think you are right that Windows builders' expectations are different
> than Unix builders' -
> especially about the library dependencies.
>
> It has never been a good idea to just "find" dependencies (like pcre, or
> openssl) on Windows because
> there is no agreed-upon place to find them, and there are potential
> conflicts if they were built
> with different versions of the MS compilers. Different versions use
> different C runtime libraries.
> There was even an incompatible change in time_t from vs2003 to vs2005
> (search for
> _USE_32BIT_TIME_T). Almost all Windows builders build all the
> dependencies, then build httpd and
> apr at the same time and with the same toolset.
>
> I think I disagree with Alexander Broekhuis' enthusiastic support of using
> CMake's "find" functions.
> These functions work well on other systems, but are more trouble than
> help on Windows. For
> example: FIND_PACKAGE(OpenSSL) will find this version on Windows:
> http://www.slproweb.com/products/Win32OpenSSL.html FIND_PACKAGE(ZLIB)
> will find GnuWin32's zlib.
> The user needs to be very careful that an unexpected library is not
> automatically found by these
> functions.
>
> The existing practice on Windows is to put the dependency source trees in
> srclib, build them there,
> but not install them. apr (& apr-util) go in srclib too. apr is
> automatically built with httpd.
>
> I think a better practice would be to build the dependencies elsewhere,
> and install them into
> srclib. I put instructions for doing things this way at:
> http://people.apache.org/~tdonovan/cmake/BuildDependencies.txt
> to show what I mean. The practice of building srclib\apr along with httpd
> is useful - and pretty
> easy to do in CMake. GUI users expect to see the apr projects in the same
> project list as httpd and
> all the module projects. I suggest the httpd CMakeLists.txt continue to
> support an included apr in
> srclib. Also, if the default location for apr and the many dependency
> libraries could be srclib -
> Gregg's objection to long command-lines might be addressed by just putting
> all the dependencies there.
>
Does this address your concern to any great extent?
* Putting the dependencies in srclib means you'll install them to the same
prefix.
* Installing things to the same prefix allows them to be easily found due
to that (instead of due to living in srclib), and having them found due to
common prefix helps users like you that like dependencies stored in srclib
as well as users like me that want everything clearly separate. (Imagine
building 30 different open source projects, and maybe httpd needs pcre and
libxml2 and openssl and so forth, but a lot of other projects need them to,
so it doesn't make sense for them to be subservient to httpd.)
* We're missing the Makefile.win replacement that ties everything together.
>
> I agree with Gregg that installing the runtime dll's (pcre.dll, iconv.dll,
> libeay.dll, etc.) along
> with httpd is a good idea on Windows. It is hard to rely on the system
> PATH, or rely on agreed-upon
> directories for these dependencies, especially if they need to be built
> with the same compiler version.
>
I guess I'm stubborn, but I want to see how far I can get by installing the
packages to a common prefix, just like on Unix. I don't yet see why one
package has to own the installation of another package's binaries.
We'll see. At any rate, it seems to me that this is a job for the
Makefile.win replacement???
>
> I haven't successfully built httpd (& apr) with your CMakeLists.txt files
> yet - but I will keep
> trying. One thing currently throwing me a curve is
> LIBXML2_ICONV_INCLUDE_DIR ? Is the expectation
> that the two dependencies (libiconv and libxml2) are installed into a
> common directory tree? True -
> libxml2 should be linked with libiconv - but they are still separate
> dependencies. I have them in
> srclib\libiconv and srclib\libxml2.
>
Re: LIBXML2_ICONV_INCLUDE_DIR... This is a very muddy concept :(
libxml2 on Windows may or may not need GNU iconv, depending on how you
configure libxml2 (I've built both ways).
LIBXML2_ICONV_LIBRARIES and LIBXML2_ICONV_INCLUDE_DIR essentially mean:
If your build of libxml2 needs iconv, then set these to the name of the
iconv library and the directory with iconv include files. If your build of
libxml2 does not need iconv, leave them unset.
These could be set automatically by running a small configure test to see
if iconv is needed, and in turn looking in CMAKE_INSTALL_PREFIX for iconv.
Some of us need to build everything with no LGPL stuff anywhere, hence my
support (however crude) for building the different flavors of libxml2.
>
> I'll keep at it - and thanks again for all your hard work.
>
> Regards,
> -tom-
>
>
>
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Tom Donovan <do...@bellatlantic.net>.
On 09/01/2013 09:55 AM, Jeff Trawick wrote:
> On Sun, Sep 1, 2013 at 9:37 AM, Guenter Knauf <fuankg@apache.org <ma...@apache.org>> wrote:
>
> Hi Jeff,
> 1st of all a big thanks from me that you picked this up!
> As you might imagine I'm on your side - means I love to have a full-automatic build without user
> interaction, and a resulting buildlog text file which I can later parse with a script for errors
> or success.
> I have such working fine with the current VC build stuff + VC6, but that doesnt work for any
> later VC versions ...
> please keep up your work on this - its certainly a good alternative way for building the windows
> binaries;
> I'm currently swamped with other stuff, but once I have the time I will certainly start playing
> around with the cmake stuff, and hope that I can help to improve it if needed.
>
> thanks, Gün.
>
>
> Thanks for showing up :) I'm tired of taking a beating from the non-automated crowd :)
>
> But seriously, there's a lot of good information in the thread about expectations and approaches,
> and even in the short term (last couple of hours) I've been motivated to revisit some of my initial
> cmake implementation to get rid of a number of required settings that shouldn't be needed for
> typical installations.
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
Jeff,
Let me second Guenter's thanks - you brought this whole effort much further than I ever could in
such a short time. Much appreciated! I really look forward to using CMake for Windows builds
instead of the crusty old Makefile.win & VC project conversion steps we have now.
I think you are right that Windows builders' expectations are different than Unix builders' -
especially about the library dependencies.
It has never been a good idea to just "find" dependencies (like pcre, or openssl) on Windows because
there is no agreed-upon place to find them, and there are potential conflicts if they were built
with different versions of the MS compilers. Different versions use different C runtime libraries.
There was even an incompatible change in time_t from vs2003 to vs2005 (search for
_USE_32BIT_TIME_T). Almost all Windows builders build all the dependencies, then build httpd and
apr at the same time and with the same toolset.
I think I disagree with Alexander Broekhuis' enthusiastic support of using CMake's "find" functions.
These functions work well on other systems, but are more trouble than help on Windows. For
example: FIND_PACKAGE(OpenSSL) will find this version on Windows:
http://www.slproweb.com/products/Win32OpenSSL.html FIND_PACKAGE(ZLIB) will find GnuWin32's zlib.
The user needs to be very careful that an unexpected library is not automatically found by these
functions.
The existing practice on Windows is to put the dependency source trees in srclib, build them there,
but not install them. apr (& apr-util) go in srclib too. apr is automatically built with httpd.
I think a better practice would be to build the dependencies elsewhere, and install them into
srclib. I put instructions for doing things this way at:
http://people.apache.org/~tdonovan/cmake/BuildDependencies.txt
to show what I mean. The practice of building srclib\apr along with httpd is useful - and pretty
easy to do in CMake. GUI users expect to see the apr projects in the same project list as httpd and
all the module projects. I suggest the httpd CMakeLists.txt continue to support an included apr in
srclib. Also, if the default location for apr and the many dependency libraries could be srclib -
Gregg's objection to long command-lines might be addressed by just putting all the dependencies there.
I agree with Gregg that installing the runtime dll's (pcre.dll, iconv.dll, libeay.dll, etc.) along
with httpd is a good idea on Windows. It is hard to rely on the system PATH, or rely on agreed-upon
directories for these dependencies, especially if they need to be built with the same compiler version.
I haven't successfully built httpd (& apr) with your CMakeLists.txt files yet - but I will keep
trying. One thing currently throwing me a curve is LIBXML2_ICONV_INCLUDE_DIR ? Is the expectation
that the two dependencies (libiconv and libxml2) are installed into a common directory tree? True -
libxml2 should be linked with libiconv - but they are still separate dependencies. I have them in
srclib\libiconv and srclib\libxml2.
I'll keep at it - and thanks again for all your hard work.
Regards,
-tom-
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Sep 1, 2013 at 9:37 AM, Guenter Knauf <fu...@apache.org> wrote:
> Hi Jeff,
> 1st of all a big thanks from me that you picked this up!
> As you might imagine I'm on your side - means I love to have a
> full-automatic build without user interaction, and a resulting buildlog
> text file which I can later parse with a script for errors or success.
> I have such working fine with the current VC build stuff + VC6, but that
> doesnt work for any later VC versions ...
> please keep up your work on this - its certainly a good alternative way
> for building the windows binaries;
> I'm currently swamped with other stuff, but once I have the time I will
> certainly start playing around with the cmake stuff, and hope that I can
> help to improve it if needed.
>
> thanks, Gün.
>
Thanks for showing up :) I'm tired of taking a beating from the
non-automated crowd :)
But seriously, there's a lot of good information in the thread about
expectations and approaches, and even in the short term (last couple of
hours) I've been motivated to revisit some of my initial cmake
implementation to get rid of a number of required settings that shouldn't
be needed for typical installations.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Guenter Knauf <fu...@apache.org>.
Hi Jeff,
1st of all a big thanks from me that you picked this up!
As you might imagine I'm on your side - means I love to have a
full-automatic build without user interaction, and a resulting buildlog
text file which I can later parse with a script for errors or success.
I have such working fine with the current VC build stuff + VC6, but that
doesnt work for any later VC versions ...
please keep up your work on this - its certainly a good alternative way
for building the windows binaries;
I'm currently swamped with other stuff, but once I have the time I will
certainly start playing around with the cmake stuff, and hope that I can
help to improve it if needed.
thanks, Gün.
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sun, Sep 1, 2013 at 6:22 AM, Steffen <in...@apachelounge.com> wrote:
> You wrote:
> .... GUI? I realize that GUI operations may be fine for you and Steffan
> and many others, but a build system that requires manual/GUI intervention
> is unsuitable for typical release build and packaging requirements.....
>
> I hope Steffan is me and not Stefan F
>
Stefan F doesn't mess with Windows as far as I can tell.
>
> I do for over 10 years “typical release builds” in 12 flavors at
> www.apachelounge.com with success and is downloaded by millions , I do
> not see your point that it is unsuitable. Indeed I have a few clicks now,
> should be easy to make a .bat/powershell to automate. But I do not want
> that, I want no silence building. Btw: In fact there are one click
> scripts around (and mentioned here on the list) and I can recall Pierre
> Joyce who proposed here (no follow up) a new one click build system based
> on the PHP way.
>
We'll never agree on this. You don't have any sort of argument for me nor
me for you. (And I have a bit of experience myself with products on
Windows that use open source software.)
The widely accepted practice is that software products are built and
regression tested hands free. If you are successful without that, good for
you.
>
> Btw. With cmake you need a lot more keyboard strokes then the few clicks
> with VC GUI, so what is manual [image: Smile]
>
>
I store those keyboard strokes in version control and they are replayed.
> Still investigating the compiler/link/other options cmake uses as said in
> the other post. In addition to optimization/debug/tracing options, I make
> on request special builds for specific hardware/processors and/or windows
> versions, oh so easy now.
>
Yeah, there's a lot to be learned there.
>
> What do you mean with “package requirement” on Windows I do not know what
> to package. Or do you mean integrating with other (commercial) software,
> that is no issue here. They just pick up a build from AL and make an
> installer around it with their own software. No issues reported by them.
>
I mean putting all the pieces together, building any sort of deliverable
starting with source code -- whatever you deliver to end users.
>
> Hard to react for me on your other arguments, to technical and mostly
> developer versus typical windows user/admin. I understand your points from
> a *nix developer point of few, but please understand that we are not
> developers but Windows users/admins. Such a discussion can be endless like
> *.nix versus Win.
>
> That you as a developer have problems with Win build system as it now is,
> is hardly to believe. A .dsp and makefile file is hardly changed all that
> years
>
We are hand editing artifacts originally generated by a Microsoft product
that isn't available for purchase (or from MSDN), that then requires some
odd conversions in order to use with modern tools*. In that context, the
lack of change in the format is not good.
*Doesn't it take more than one level of Visual Studio to get it into
something that the most recent versions will use?
> and as Gregg said you have to know to find the place where to insert a
> line for the build system with a new module. And with a new module dsp,
> Gregg and others can pick it up and you have no worry (open source to
> help). Off-topic: Coding is an other story, the “if def Win” stuff. I have
> a good experience with module developers, in an early stage they hand me
> over the code to test it. I remember the old days when mod_fcgid was not
> ASF, together with the author we implemented the Win additions/changes.
> Also mod_security is handed me over before beta/rc
>
> I have to say that the Windows community appreciates very much that there
> is such attention, there where other days.
>
> Next week I have time to give cmake a try. Who knows it is not that worse
> as it looks like now.
>
> Regards,
>
> Steffen
>
> Ps.
> Still strange that you do not want cmake with *nix.
>
A flexible, non-GUI build that supports a fairly wide range of tools is
already implemented for *nix.
>
>
> *From:* Jeff Trawick <tr...@gmail.com>
> *Sent:* Sunday, 1 September, 2013 05:47
> *To:* Apache HTTP Server Development List <de...@httpd.apache.org>
> *Subject:* *********** Re: will anyone build httpd/apr with cmake on
> Windows?
>
> On Sat, Aug 31, 2013 at 10:09 PM, Gregg Smith <gl...@gknw.net> wrote:
>
>> Hi Jeff,
>>
>> I see Steffen has chimed in and have read the reply as well, but I just
>> want to cover a couple points now, I need to ponder on some of your other
>> comments.
>>
>> On 8/31/2013 2:41 PM, Jeff Trawick wrote:
>>
>>> On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <gls@gknw.net <mailto:
>>> gls@gknw.net>> wrote:
>>>
>>> Hi Jeff,
>>>
>>> Well, putting on my Apache Haus hat my first impressions are "What
>>> a nightmare!" :)
>>> I must say I prefer the more turnkey approach we enjoy these days,
>>>
>>>
>>> I'm not 100% sure what you mean by the more turnkey approach. I guess
>>> that is putting support libraries under httpd/srclib and having the httpd
>>> build sort of orchestrate putting the libraries together, installing the
>>> stuff httpd cares about, etc?
>>>
>>
>> More the fact that httpd, APR, APU & APIconv are built in one click of
>> the build button. Granted, other dependencies have to be built separately
>> including now PCRE as of 2.3.
>>
>>
>> Although I do try to work on Windows from time to time, I am no expert in
>>> building and putting together stuff in the current way. Here is my own
>>> admittedly ignorant understanding of the current build system (please add
>>> corrections):
>>>
>>> * I have to do multiple conversions of the project files in svn to run
>>> with the latest Visual Studio stuff
>>>
>>
>> With that obstinate nightmare called VC10, that was the only way I could
>> get it to be successful (converting to VC9 first), VC11 this is not the
>> case. It still has quirks, the intellinonsense in VC11 is a pain, but as
>> long as we regenerate apr/apu.h files during every build, it's going to
>> rebuild those a few times during a single build session. I need to look
>> again and see if it can be disabled though I doubt it. I've worked around
>> it.
>>
>> As Steffen mentioned, it needs a little minor adjusting to get it
>> working. VC11 does not like embedding the manifest in ApacheMonitor, nor
>> does it like using precompiled headers in APR-Iconv. For whatever reason
>> for me, it cannot find libxml2.lib for mod_proxy_html/xml2enc, even though
>> it has no problems with any other modules dependencies . I haven't figured
>> this one out yet. I have to build on a VM somewhere in the world and the
>> added time/complexity has kept me from getting anywhere fast with this.
>>
>>
>> * Manual and/or Visual Studio GUI work is required to build everything
>>> using recent Microsoft tools.
>>>
>> Huh? Manual? VC GUI yes, because we do not have a full set of nmake
>> makefiles in svn, like there are for APR/APU.
>
>
> GUI? I realize that GUI operations may be fine for you and Steffan and
> many others, but a build system that requires manual/GUI intervention is
> unsuitable for typical release build and packaging requirements. Windows
> build support in httpd/apr is defective if it can't be built with modern
> Microsoft compilers without manual intervention. That isn't to say, of
> course, that GUI ways of doing things are bad or inappropriate for the
> projects to provide. (cmake generates project files too, but somebody that
> likes to build in the Visual Studio GUI would need to try it and compare.)
>
> Surely there's a way to script what you're doing?
>
>
>
>>
>> * I don't understand how to get Makefiles that build things the right way
>>> for the latest Microsoft compilers
>>>
>> What's "the right way?" If you just mean generating the makefiles, yes,
>> that is M$ deciding to remove the feature after VC6.
>>
>>
>> * There's a high ratio of gorp to critical information in the Windows
>>> build files we maintain in svn, and I feel that I'm going to break
>>> something every time I try to the required new gorp in order to add a file
>>> or module or whatever to the build for Windows.
>>>
>>
>> Nah, you've done well so far. Granted, there's only a few lines you need
>> to concern yourself with mostly. CPP, LINK32 & the Source file stuff at
>> the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked!
>>
>> Adding a module is another story I admit. It's more just knowing what and
>> where. There at least are example in the svn of just adding a module. For
>> instance http://svn.apache.org/r1436058
>>
>> Then there's also the "PING: Windows folks" on dev@ possibility,
>> explaining what was added/subtracted/changed that would require an
>> adjustment to the build. Someone knowing with commit access would see this
>> and gladly make any necessary changes, then again, maybe not.
>
>
> Sometimes I've added things in a way that works, sometimes I've added
> things in a way that doesn't. I forgot about adding mod_authnz_fcgi.dsp
> and a reference to it, and nobody else picked up on that either (yet). My
> recollection is that other people have mixed results too.
>
> FWIW, the one line it takes to support that module with cmake is
>
> "modules/aaa/mod_authnz_fcgi.c+I+FastCGI authorizer-based authentication
> and authorization"
>
> (Modules which require extra defines or libraries would have another line
> for every special requirement -- include or define or extra library or
> prereq.)
>
>
>
>>
>>
>> * People have other build tools on Windows that they want to use, and all
>>> that Visual Studio stuff is essentially useless to them except for trying
>>> to reverse engineer intention out of the generated gorp; certainly not
>>> useful for actually building. (I've only tried "NMake Makefile"-based
>>> builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual
>>> Studio 2012 tools; I haven't tried non-Microsoft compilers yet.)
>>>
>>
>> What people? What other tools?
>
>
> Considering httpd and apr:
>
> What people/What other tools on Windows
>
> various including some that provided patches/autoconf-based build in Cygwin
> me + various others including multiple people that provided
> patches/autoconf-based build using MinGW
> product I've worked on/Intel compiler using modified VC6-exported makefiles
>
> Code can get better when you check it with more compilers. E.g.,
> Windows-specific code in httpd and apr has gotten better based on building
> with gcc.
>
>
>>
>>
>>
>>> My build requirements that aren't met with the current system:
>>>
>>> * statically linking third-party modules with the server (e.g.,
>>> including in libhttpd, editing modules.c)
>>> * fine-grained control over which modules are built and which are loaded
>>> by default
>>>
>>
>> Who am I to decide just what 3rd party modules my users want to use. Not
>> only that, when there is a new version of a module, do I really want to
>> rebuild and entire Apache? No, I just build the new version of the module.
>> That way if Joe User doesn't want mod_auth_ntlm, he doesn't have to
>> download it and add it to his Apache and it doesn't have to be absorbing
>> space on the hard drive. I do understand this ability is possible in the
>> unix build though, I've built on Linux a couple times.
>>
>> I really do get it and the admin whos corporate policy is to download
>> only from ASF or build it in house could have use for this.
>
>
> FWIW, that's not something you do with mod_php or such. One particular
> case: it can be useful to augment the core server with additional code, and
> organizing it as a statically linked module gets you most of the
> integration points for free. The autoconf-based build had support for that
> all long.
>
> At any rate, I use it, you don't, peace on earth ;)
>
>
>>
>>
>> * absolutely no requirement to put support libraries in srclib/*
>>>
>>
>> I actually had a php developer ask me why we didn't use just a *single*
>> dependency tree;
>>
>> /deps
>> /deps/bin
>> /deps/include
>> /deps/lib
>>
>> the only answer I came up with was "because this works!"
>>
>>
>> * ability to build for Windows and various Unixy platforms using the same
>>> basic flow
>>>
>> No comment.
>>
>>
>>> But really, who is going to use this on Windows? Who are the noobs?
>>> Developers?
>>>
>>
>> The noobs are Joe Windows Apache User who one day decides to grab a free
>> copy of VC++ Express and give it a whirl. I was that person once long ago
>> in the 1.3 days. If only there were express versions back then.
>>
>>
>>
>>> Perhaps I'm misunderstanding something, but installing support libraries
>>> to the same prefix lets cmake find stuff with zero code, and the intention
>>> is to put things in the same prefix anyway, right? If you wanted to put
>>> the sources under srclib but still install to the same prefix it still
>>> works?
>>>
>>
>> I get it now and that was mostly what I had, my downfall was using -D
>> pointing to optional library folders instead of library files (my bad).
>>
>>
>> Somehow I think that a wrapper script/makefiles to put together the
>>> independent builds of the various projects is the missing piece to a lot of
>>> these concerns. I would have thought that different
>>> developers/bundlers/etc. would have their own way to glue things together
>>> that makes sense for them, but perhaps some default is needed.
>>>
>>
>> See makefile.win, it's all there. Installs all the mess including any
>> optional DLLs to where they belong.
>
>
> I certainly agree with the value of having a makefile/script which pulls
> it all together. Tying all the existing Windows build together without
> that is about like doing the same with cmake.
>
>
>>
>>
>>
>>> I've never actually "nmake install" any dependency, it's rather
>>> useless on Windows. I have to create multiple mod_ssl with
>>> different openssl versions so installing openssl would limit that.
>>> This might help you understand my suggestion about dependencies :)
>>>
>>>
>>> I guess with the cmake build of httpd you start with these openssl
>>> builds or installs (whatever it takes for FindOpenSSL to deal with):
>>>
>>> \openssl1
>>> \openssl2
>>> \openssl3
>>>
>>> You build httpd once using the desired feature set and you specify one
>>> of these openssl trees with the cmake settings CMAKE_LIBRARY_PATH/CMAKE_
>>> **INCLUDE_PATH.
>>>
>>> Rename that first mod_ssl.so mod_ssl_for_openssl1.so
>>>
>>> Build httpd two more times using minimal feature set (save build time),
>>> setting the CMAKE path used to find prereqs to those other builds of
>>> openssl.
>>>
>>> ARGH! I do somewhat similar though, yours just sounds harder.
>>
>>
>> How does that work for you today? How much code gets rebuilt as you
>>> prepare the additional mod_ssl builds?
>>>
>>
>> 2 OpenSSL builds in srclib, one named openssl and another named openssl-x
>> (x being 098 or 101). Build Apache and Install. Rename the OpenSSL folders,
>> change Install folder, rebuild just the few items that actually link to
>> OpenSSL, Install again. GUI is handy for this since you can rebuild a
>> single project easily.
>>
>> This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so
>> if Apache is built with 1.0.1, it will not start. We offer downgrade zips
>> for this purpose. mod_fcgid remedies this problem but some people would
>> rather use mod_php.
>
>
> Sorry, but I just gotta say it -- when you write "GUI is handy" I read
> "unrepeatable procedure that can't be stored in version control" or, at
> best, "hard-to-maintain GUI driver script that presses buttons " Why isn't
> something that the computer does for you automatically while you do
> something that humans are good at easier than something that requires you
> to press buttons at certain points?
>
>
>>
>>
>> Thanks so much for spending the time!!
>>>
>>
>> No problem, I figured I should give it a whirl.
>>
>> Gregg
>>
>
> Best wishes!
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Steffen <in...@apachelounge.com>.
You wrote:
.... GUI? I realize that GUI operations may be fine for you and Steffan and many others, but a build system that requires manual/GUI intervention is unsuitable for typical release build and packaging requirements.....
I hope Steffan is me and not Stefan F
I do for over 10 years “typical release builds” in 12 flavors at www.apachelounge.com with success and is downloaded by millions , I do not see your point that it is unsuitable. Indeed I have a few clicks now, should be easy to make a .bat/powershell to automate. But I do not want that, I want no silence building. Btw: In fact there are one click scripts around (and mentioned here on the list) and I can recall Pierre Joyce who proposed here (no follow up) a new one click build system based on the PHP way.
Btw. With cmake you need a lot more keyboard strokes then the few clicks with VC GUI, so what is manual
Still investigating the compiler/link/other options cmake uses as said in the other post. In addition to optimization/debug/tracing options, I make on request special builds for specific hardware/processors and/or windows versions, oh so easy now.
What do you mean with “package requirement” on Windows I do not know what to package. Or do you mean integrating with other (commercial) software, that is no issue here. They just pick up a build from AL and make an installer around it with their own software. No issues reported by them.
Hard to react for me on your other arguments, to technical and mostly developer versus typical windows user/admin. I understand your points from a *nix developer point of few, but please understand that we are not developers but Windows users/admins. Such a discussion can be endless like *.nix versus Win.
That you as a developer have problems with Win build system as it now is, is hardly to believe. A .dsp and makefile file is hardly changed all that years and as Gregg said you have to know to find the place where to insert a line for the build system with a new module. And with a new module dsp, Gregg and others can pick it up and you have no worry (open source to help). Off-topic: Coding is an other story, the “if def Win” stuff. I have a good experience with module developers, in an early stage they hand me over the code to test it. I remember the old days when mod_fcgid was not ASF, together with the author we implemented the Win additions/changes. Also mod_security is handed me over before beta/rc
I have to say that the Windows community appreciates very much that there is such attention, there where other days.
Next week I have time to give cmake a try. Who knows it is not that worse as it looks like now.
Regards,
Steffen
Ps.
Still strange that you do not want cmake with *nix.
From: Jeff Trawick
Sent: Sunday, 1 September, 2013 05:47
To: Apache HTTP Server Development List
Subject: *********** Re: will anyone build httpd/apr with cmake on Windows?
On Sat, Aug 31, 2013 at 10:09 PM, Gregg Smith <gl...@gknw.net> wrote:
Hi Jeff,
I see Steffen has chimed in and have read the reply as well, but I just want to cover a couple points now, I need to ponder on some of your other comments.
On 8/31/2013 2:41 PM, Jeff Trawick wrote:
On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <gls@gknw.net <ma...@gknw.net>> wrote:
Hi Jeff,
Well, putting on my Apache Haus hat my first impressions are "What
a nightmare!" :)
I must say I prefer the more turnkey approach we enjoy these days,
I'm not 100% sure what you mean by the more turnkey approach. I guess that is putting support libraries under httpd/srclib and having the httpd build sort of orchestrate putting the libraries together, installing the stuff httpd cares about, etc?
More the fact that httpd, APR, APU & APIconv are built in one click of the build button. Granted, other dependencies have to be built separately including now PCRE as of 2.3.
Although I do try to work on Windows from time to time, I am no expert in building and putting together stuff in the current way. Here is my own admittedly ignorant understanding of the current build system (please add corrections):
* I have to do multiple conversions of the project files in svn to run with the latest Visual Studio stuff
With that obstinate nightmare called VC10, that was the only way I could get it to be successful (converting to VC9 first), VC11 this is not the case. It still has quirks, the intellinonsense in VC11 is a pain, but as long as we regenerate apr/apu.h files during every build, it's going to rebuild those a few times during a single build session. I need to look again and see if it can be disabled though I doubt it. I've worked around it.
As Steffen mentioned, it needs a little minor adjusting to get it working. VC11 does not like embedding the manifest in ApacheMonitor, nor does it like using precompiled headers in APR-Iconv. For whatever reason for me, it cannot find libxml2.lib for mod_proxy_html/xml2enc, even though it has no problems with any other modules dependencies . I haven't figured this one out yet. I have to build on a VM somewhere in the world and the added time/complexity has kept me from getting anywhere fast with this.
* Manual and/or Visual Studio GUI work is required to build everything using recent Microsoft tools.
Huh? Manual? VC GUI yes, because we do not have a full set of nmake makefiles in svn, like there are for APR/APU.
GUI? I realize that GUI operations may be fine for you and Steffan and many others, but a build system that requires manual/GUI intervention is unsuitable for typical release build and packaging requirements. Windows build support in httpd/apr is defective if it can't be built with modern Microsoft compilers without manual intervention. That isn't to say, of course, that GUI ways of doing things are bad or inappropriate for the projects to provide. (cmake generates project files too, but somebody that likes to build in the Visual Studio GUI would need to try it and compare.)
Surely there's a way to script what you're doing?
* I don't understand how to get Makefiles that build things the right way for the latest Microsoft compilers
What's "the right way?" If you just mean generating the makefiles, yes, that is M$ deciding to remove the feature after VC6.
* There's a high ratio of gorp to critical information in the Windows build files we maintain in svn, and I feel that I'm going to break something every time I try to the required new gorp in order to add a file or module or whatever to the build for Windows.
Nah, you've done well so far. Granted, there's only a few lines you need to concern yourself with mostly. CPP, LINK32 & the Source file stuff at the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked!
Adding a module is another story I admit. It's more just knowing what and where. There at least are example in the svn of just adding a module. For instance http://svn.apache.org/r1436058
Then there's also the "PING: Windows folks" on dev@ possibility, explaining what was added/subtracted/changed that would require an adjustment to the build. Someone knowing with commit access would see this and gladly make any necessary changes, then again, maybe not.
Sometimes I've added things in a way that works, sometimes I've added things in a way that doesn't. I forgot about adding mod_authnz_fcgi.dsp and a reference to it, and nobody else picked up on that either (yet). My recollection is that other people have mixed results too.
FWIW, the one line it takes to support that module with cmake is
"modules/aaa/mod_authnz_fcgi.c+I+FastCGI authorizer-based authentication and authorization"
(Modules which require extra defines or libraries would have another line for every special requirement -- include or define or extra library or prereq.)
* People have other build tools on Windows that they want to use, and all that Visual Studio stuff is essentially useless to them except for trying to reverse engineer intention out of the generated gorp; certainly not useful for actually building. (I've only tried "NMake Makefile"-based builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual Studio 2012 tools; I haven't tried non-Microsoft compilers yet.)
What people? What other tools?
Considering httpd and apr:
What people/What other tools on Windows
various including some that provided patches/autoconf-based build in Cygwin
me + various others including multiple people that provided patches/autoconf-based build using MinGW
product I've worked on/Intel compiler using modified VC6-exported makefiles
Code can get better when you check it with more compilers. E.g., Windows-specific code in httpd and apr has gotten better based on building with gcc.
My build requirements that aren't met with the current system:
* statically linking third-party modules with the server (e.g., including in libhttpd, editing modules.c)
* fine-grained control over which modules are built and which are loaded by default
Who am I to decide just what 3rd party modules my users want to use. Not only that, when there is a new version of a module, do I really want to rebuild and entire Apache? No, I just build the new version of the module. That way if Joe User doesn't want mod_auth_ntlm, he doesn't have to download it and add it to his Apache and it doesn't have to be absorbing space on the hard drive. I do understand this ability is possible in the unix build though, I've built on Linux a couple times.
I really do get it and the admin whos corporate policy is to download only from ASF or build it in house could have use for this.
FWIW, that's not something you do with mod_php or such. One particular case: it can be useful to augment the core server with additional code, and organizing it as a statically linked module gets you most of the integration points for free. The autoconf-based build had support for that all long.
At any rate, I use it, you don't, peace on earth ;)
* absolutely no requirement to put support libraries in srclib/*
I actually had a php developer ask me why we didn't use just a *single* dependency tree;
/deps
/deps/bin
/deps/include
/deps/lib
the only answer I came up with was "because this works!"
* ability to build for Windows and various Unixy platforms using the same basic flow
No comment.
But really, who is going to use this on Windows? Who are the noobs? Developers?
The noobs are Joe Windows Apache User who one day decides to grab a free copy of VC++ Express and give it a whirl. I was that person once long ago in the 1.3 days. If only there were express versions back then.
Perhaps I'm misunderstanding something, but installing support libraries to the same prefix lets cmake find stuff with zero code, and the intention is to put things in the same prefix anyway, right? If you wanted to put the sources under srclib but still install to the same prefix it still works?
I get it now and that was mostly what I had, my downfall was using -D pointing to optional library folders instead of library files (my bad).
Somehow I think that a wrapper script/makefiles to put together the independent builds of the various projects is the missing piece to a lot of these concerns. I would have thought that different developers/bundlers/etc. would have their own way to glue things together that makes sense for them, but perhaps some default is needed.
See makefile.win, it's all there. Installs all the mess including any optional DLLs to where they belong.
I certainly agree with the value of having a makefile/script which pulls it all together. Tying all the existing Windows build together without that is about like doing the same with cmake.
I've never actually "nmake install" any dependency, it's rather
useless on Windows. I have to create multiple mod_ssl with
different openssl versions so installing openssl would limit that.
This might help you understand my suggestion about dependencies :)
I guess with the cmake build of httpd you start with these openssl builds or installs (whatever it takes for FindOpenSSL to deal with):
\openssl1
\openssl2
\openssl3
You build httpd once using the desired feature set and you specify one of these openssl trees with the cmake settings CMAKE_LIBRARY_PATH/CMAKE_INCLUDE_PATH.
Rename that first mod_ssl.so mod_ssl_for_openssl1.so
Build httpd two more times using minimal feature set (save build time), setting the CMAKE path used to find prereqs to those other builds of openssl.
ARGH! I do somewhat similar though, yours just sounds harder.
How does that work for you today? How much code gets rebuilt as you prepare the additional mod_ssl builds?
2 OpenSSL builds in srclib, one named openssl and another named openssl-x (x being 098 or 101). Build Apache and Install. Rename the OpenSSL folders, change Install folder, rebuild just the few items that actually link to OpenSSL, Install again. GUI is handy for this since you can rebuild a single project easily.
This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so if Apache is built with 1.0.1, it will not start. We offer downgrade zips for this purpose. mod_fcgid remedies this problem but some people would rather use mod_php.
Sorry, but I just gotta say it -- when you write "GUI is handy" I read "unrepeatable procedure that can't be stored in version control" or, at best, "hard-to-maintain GUI driver script that presses buttons " Why isn't something that the computer does for you automatically while you do something that humans are good at easier than something that requires you to press buttons at certain points?
Thanks so much for spending the time!!
No problem, I figured I should give it a whirl.
Gregg
Best wishes!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Aug 31, 2013 at 10:09 PM, Gregg Smith <gl...@gknw.net> wrote:
> Hi Jeff,
>
> I see Steffen has chimed in and have read the reply as well, but I just
> want to cover a couple points now, I need to ponder on some of your other
> comments.
>
> On 8/31/2013 2:41 PM, Jeff Trawick wrote:
>
>> On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <gls@gknw.net <mailto:
>> gls@gknw.net>> wrote:
>>
>> Hi Jeff,
>>
>> Well, putting on my Apache Haus hat my first impressions are "What
>> a nightmare!" :)
>> I must say I prefer the more turnkey approach we enjoy these days,
>>
>>
>> I'm not 100% sure what you mean by the more turnkey approach. I guess
>> that is putting support libraries under httpd/srclib and having the httpd
>> build sort of orchestrate putting the libraries together, installing the
>> stuff httpd cares about, etc?
>>
>
> More the fact that httpd, APR, APU & APIconv are built in one click of the
> build button. Granted, other dependencies have to be built separately
> including now PCRE as of 2.3.
>
>
> Although I do try to work on Windows from time to time, I am no expert in
>> building and putting together stuff in the current way. Here is my own
>> admittedly ignorant understanding of the current build system (please add
>> corrections):
>>
>> * I have to do multiple conversions of the project files in svn to run
>> with the latest Visual Studio stuff
>>
>
> With that obstinate nightmare called VC10, that was the only way I could
> get it to be successful (converting to VC9 first), VC11 this is not the
> case. It still has quirks, the intellinonsense in VC11 is a pain, but as
> long as we regenerate apr/apu.h files during every build, it's going to
> rebuild those a few times during a single build session. I need to look
> again and see if it can be disabled though I doubt it. I've worked around
> it.
>
> As Steffen mentioned, it needs a little minor adjusting to get it working.
> VC11 does not like embedding the manifest in ApacheMonitor, nor does it
> like using precompiled headers in APR-Iconv. For whatever reason for me, it
> cannot find libxml2.lib for mod_proxy_html/xml2enc, even though it has no
> problems with any other modules dependencies . I haven't figured this one
> out yet. I have to build on a VM somewhere in the world and the added
> time/complexity has kept me from getting anywhere fast with this.
>
>
> * Manual and/or Visual Studio GUI work is required to build everything
>> using recent Microsoft tools.
>>
> Huh? Manual? VC GUI yes, because we do not have a full set of nmake
> makefiles in svn, like there are for APR/APU.
GUI? I realize that GUI operations may be fine for you and Steffan and
many others, but a build system that requires manual/GUI intervention is
unsuitable for typical release build and packaging requirements. Windows
build support in httpd/apr is defective if it can't be built with modern
Microsoft compilers without manual intervention. That isn't to say, of
course, that GUI ways of doing things are bad or inappropriate for the
projects to provide. (cmake generates project files too, but somebody that
likes to build in the Visual Studio GUI would need to try it and compare.)
Surely there's a way to script what you're doing?
>
> * I don't understand how to get Makefiles that build things the right way
>> for the latest Microsoft compilers
>>
> What's "the right way?" If you just mean generating the makefiles, yes,
> that is M$ deciding to remove the feature after VC6.
>
>
> * There's a high ratio of gorp to critical information in the Windows
>> build files we maintain in svn, and I feel that I'm going to break
>> something every time I try to the required new gorp in order to add a file
>> or module or whatever to the build for Windows.
>>
>
> Nah, you've done well so far. Granted, there's only a few lines you need
> to concern yourself with mostly. CPP, LINK32 & the Source file stuff at
> the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked!
>
> Adding a module is another story I admit. It's more just knowing what and
> where. There at least are example in the svn of just adding a module. For
> instance http://svn.apache.org/r1436058
>
> Then there's also the "PING: Windows folks" on dev@ possibility,
> explaining what was added/subtracted/changed that would require an
> adjustment to the build. Someone knowing with commit access would see this
> and gladly make any necessary changes, then again, maybe not.
Sometimes I've added things in a way that works, sometimes I've added
things in a way that doesn't. I forgot about adding mod_authnz_fcgi.dsp
and a reference to it, and nobody else picked up on that either (yet). My
recollection is that other people have mixed results too.
FWIW, the one line it takes to support that module with cmake is
"modules/aaa/mod_authnz_fcgi.c+I+FastCGI authorizer-based authentication
and authorization"
(Modules which require extra defines or libraries would have another line
for every special requirement -- include or define or extra library or
prereq.)
>
>
> * People have other build tools on Windows that they want to use, and all
>> that Visual Studio stuff is essentially useless to them except for trying
>> to reverse engineer intention out of the generated gorp; certainly not
>> useful for actually building. (I've only tried "NMake Makefile"-based
>> builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual
>> Studio 2012 tools; I haven't tried non-Microsoft compilers yet.)
>>
>
> What people? What other tools?
Considering httpd and apr:
What people/What other tools on Windows
various including some that provided patches/autoconf-based build in Cygwin
me + various others including multiple people that provided
patches/autoconf-based build using MinGW
product I've worked on/Intel compiler using modified VC6-exported makefiles
Code can get better when you check it with more compilers. E.g.,
Windows-specific code in httpd and apr has gotten better based on building
with gcc.
>
>
>> My build requirements that aren't met with the current system:
>>
>> * statically linking third-party modules with the server (e.g., including
>> in libhttpd, editing modules.c)
>> * fine-grained control over which modules are built and which are loaded
>> by default
>>
>
> Who am I to decide just what 3rd party modules my users want to use. Not
> only that, when there is a new version of a module, do I really want to
> rebuild and entire Apache? No, I just build the new version of the module.
> That way if Joe User doesn't want mod_auth_ntlm, he doesn't have to
> download it and add it to his Apache and it doesn't have to be absorbing
> space on the hard drive. I do understand this ability is possible in the
> unix build though, I've built on Linux a couple times.
>
> I really do get it and the admin whos corporate policy is to download only
> from ASF or build it in house could have use for this.
FWIW, that's not something you do with mod_php or such. One particular
case: it can be useful to augment the core server with additional code, and
organizing it as a statically linked module gets you most of the
integration points for free. The autoconf-based build had support for that
all long.
At any rate, I use it, you don't, peace on earth ;)
>
> * absolutely no requirement to put support libraries in srclib/*
>>
>
> I actually had a php developer ask me why we didn't use just a *single*
> dependency tree;
>
> /deps
> /deps/bin
> /deps/include
> /deps/lib
>
> the only answer I came up with was "because this works!"
>
>
> * ability to build for Windows and various Unixy platforms using the same
>> basic flow
>>
> No comment.
>
>
>> But really, who is going to use this on Windows? Who are the noobs?
>> Developers?
>>
>
> The noobs are Joe Windows Apache User who one day decides to grab a free
> copy of VC++ Express and give it a whirl. I was that person once long ago
> in the 1.3 days. If only there were express versions back then.
>
>
>
>> Perhaps I'm misunderstanding something, but installing support libraries
>> to the same prefix lets cmake find stuff with zero code, and the intention
>> is to put things in the same prefix anyway, right? If you wanted to put
>> the sources under srclib but still install to the same prefix it still
>> works?
>>
>
> I get it now and that was mostly what I had, my downfall was using -D
> pointing to optional library folders instead of library files (my bad).
>
>
> Somehow I think that a wrapper script/makefiles to put together the
>> independent builds of the various projects is the missing piece to a lot of
>> these concerns. I would have thought that different
>> developers/bundlers/etc. would have their own way to glue things together
>> that makes sense for them, but perhaps some default is needed.
>>
>
> See makefile.win, it's all there. Installs all the mess including any
> optional DLLs to where they belong.
I certainly agree with the value of having a makefile/script which pulls
it all together. Tying all the existing Windows build together without
that is about like doing the same with cmake.
>
>
>> I've never actually "nmake install" any dependency, it's rather
>> useless on Windows. I have to create multiple mod_ssl with
>> different openssl versions so installing openssl would limit that.
>> This might help you understand my suggestion about dependencies :)
>>
>>
>> I guess with the cmake build of httpd you start with these openssl builds
>> or installs (whatever it takes for FindOpenSSL to deal with):
>>
>> \openssl1
>> \openssl2
>> \openssl3
>>
>> You build httpd once using the desired feature set and you specify one of
>> these openssl trees with the cmake settings CMAKE_LIBRARY_PATH/CMAKE_**
>> INCLUDE_PATH.
>>
>> Rename that first mod_ssl.so mod_ssl_for_openssl1.so
>>
>> Build httpd two more times using minimal feature set (save build time),
>> setting the CMAKE path used to find prereqs to those other builds of
>> openssl.
>>
>> ARGH! I do somewhat similar though, yours just sounds harder.
>
>
> How does that work for you today? How much code gets rebuilt as you
>> prepare the additional mod_ssl builds?
>>
>
> 2 OpenSSL builds in srclib, one named openssl and another named openssl-x
> (x being 098 or 101). Build Apache and Install. Rename the OpenSSL folders,
> change Install folder, rebuild just the few items that actually link to
> OpenSSL, Install again. GUI is handy for this since you can rebuild a
> single project easily.
>
> This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so
> if Apache is built with 1.0.1, it will not start. We offer downgrade zips
> for this purpose. mod_fcgid remedies this problem but some people would
> rather use mod_php.
Sorry, but I just gotta say it -- when you write "GUI is handy" I read
"unrepeatable procedure that can't be stored in version control" or, at
best, "hard-to-maintain GUI driver script that presses buttons " Why isn't
something that the computer does for you automatically while you do
something that humans are good at easier than something that requires you
to press buttons at certain points?
>
> Thanks so much for spending the time!!
>>
>
> No problem, I figured I should give it a whirl.
>
> Gregg
>
Best wishes!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Gregg Smith <gl...@gknw.net>.
Hi Jeff,
I see Steffen has chimed in and have read the reply as well, but I just
want to cover a couple points now, I need to ponder on some of your
other comments.
On 8/31/2013 2:41 PM, Jeff Trawick wrote:
> On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <gls@gknw.net
> <ma...@gknw.net>> wrote:
>
> Hi Jeff,
> Well, putting on my Apache Haus hat my first impressions are "What
> a nightmare!" :)
> I must say I prefer the more turnkey approach we enjoy these days,
>
>
> I'm not 100% sure what you mean by the more turnkey approach. I guess
> that is putting support libraries under httpd/srclib and having the
> httpd build sort of orchestrate putting the libraries together,
> installing the stuff httpd cares about, etc?
More the fact that httpd, APR, APU & APIconv are built in one click of
the build button. Granted, other dependencies have to be built
separately including now PCRE as of 2.3.
> Although I do try to work on Windows from time to time, I am no expert
> in building and putting together stuff in the current way. Here is my
> own admittedly ignorant understanding of the current build system
> (please add corrections):
>
> * I have to do multiple conversions of the project files in svn to run
> with the latest Visual Studio stuff
With that obstinate nightmare called VC10, that was the only way I could
get it to be successful (converting to VC9 first), VC11 this is not the
case. It still has quirks, the intellinonsense in VC11 is a pain, but as
long as we regenerate apr/apu.h files during every build, it's going to
rebuild those a few times during a single build session. I need to look
again and see if it can be disabled though I doubt it. I've worked
around it.
As Steffen mentioned, it needs a little minor adjusting to get it
working. VC11 does not like embedding the manifest in ApacheMonitor, nor
does it like using precompiled headers in APR-Iconv. For whatever reason
for me, it cannot find libxml2.lib for mod_proxy_html/xml2enc, even
though it has no problems with any other modules dependencies . I
haven't figured this one out yet. I have to build on a VM somewhere in
the world and the added time/complexity has kept me from getting
anywhere fast with this.
> * Manual and/or Visual Studio GUI work is required to build everything
> using recent Microsoft tools.
Huh? Manual? VC GUI yes, because we do not have a full set of nmake
makefiles in svn, like there are for APR/APU.
> * I don't understand how to get Makefiles that build things the right
> way for the latest Microsoft compilers
What's "the right way?" If you just mean generating the makefiles, yes,
that is M$ deciding to remove the feature after VC6.
> * There's a high ratio of gorp to critical information in the Windows
> build files we maintain in svn, and I feel that I'm going to break
> something every time I try to the required new gorp in order to add a
> file or module or whatever to the build for Windows.
Nah, you've done well so far. Granted, there's only a few lines you need
to concern yourself with mostly. CPP, LINK32 & the Source file stuff at
the bottom. You handled adding util_fcgi.c to libhttpd with ease it looked!
Adding a module is another story I admit. It's more just knowing what
and where. There at least are example in the svn of just adding a
module. For instance http://svn.apache.org/r1436058
Then there's also the "PING: Windows folks" on dev@ possibility,
explaining what was added/subtracted/changed that would require an
adjustment to the build. Someone knowing with commit access would see
this and gladly make any necessary changes, then again, maybe not.
> * People have other build tools on Windows that they want to use, and
> all that Visual Studio stuff is essentially useless to them except for
> trying to reverse engineer intention out of the generated gorp;
> certainly not useful for actually building. (I've only tried "NMake
> Makefile"-based builds using a mix of 32-bit, 64-bit, Visual Studio
> 2010 tools, and Visual Studio 2012 tools; I haven't tried
> non-Microsoft compilers yet.)
What people? What other tools?
>
> My build requirements that aren't met with the current system:
>
> * statically linking third-party modules with the server (e.g.,
> including in libhttpd, editing modules.c)
> * fine-grained control over which modules are built and which are
> loaded by default
Who am I to decide just what 3rd party modules my users want to use. Not
only that, when there is a new version of a module, do I really want to
rebuild and entire Apache? No, I just build the new version of the
module. That way if Joe User doesn't want mod_auth_ntlm, he doesn't have
to download it and add it to his Apache and it doesn't have to be
absorbing space on the hard drive. I do understand this ability is
possible in the unix build though, I've built on Linux a couple times.
I really do get it and the admin whos corporate policy is to download
only from ASF or build it in house could have use for this.
> * absolutely no requirement to put support libraries in srclib/*
I actually had a php developer ask me why we didn't use just a *single*
dependency tree;
/deps
/deps/bin
/deps/include
/deps/lib
the only answer I came up with was "because this works!"
> * ability to build for Windows and various Unixy platforms using the
> same basic flow
No comment.
>
> But really, who is going to use this on Windows? Who are the noobs?
> Developers?
The noobs are Joe Windows Apache User who one day decides to grab a free
copy of VC++ Express and give it a whirl. I was that person once long
ago in the 1.3 days. If only there were express versions back then.
>
> Perhaps I'm misunderstanding something, but installing support
> libraries to the same prefix lets cmake find stuff with zero code, and
> the intention is to put things in the same prefix anyway, right? If
> you wanted to put the sources under srclib but still install to the
> same prefix it still works?
I get it now and that was mostly what I had, my downfall was using -D
pointing to optional library folders instead of library files (my bad).
> Somehow I think that a wrapper script/makefiles to put together the
> independent builds of the various projects is the missing piece to a
> lot of these concerns. I would have thought that different
> developers/bundlers/etc. would have their own way to glue things
> together that makes sense for them, but perhaps some default is needed.
See makefile.win, it's all there. Installs all the mess including any
optional DLLs to where they belong.
>
> I've never actually "nmake install" any dependency, it's rather
> useless on Windows. I have to create multiple mod_ssl with
> different openssl versions so installing openssl would limit that.
> This might help you understand my suggestion about dependencies :)
>
>
> I guess with the cmake build of httpd you start with these openssl
> builds or installs (whatever it takes for FindOpenSSL to deal with):
>
> \openssl1
> \openssl2
> \openssl3
>
> You build httpd once using the desired feature set and you specify one
> of these openssl trees with the cmake settings
> CMAKE_LIBRARY_PATH/CMAKE_INCLUDE_PATH.
>
> Rename that first mod_ssl.so mod_ssl_for_openssl1.so
>
> Build httpd two more times using minimal feature set (save build
> time), setting the CMAKE path used to find prereqs to those other
> builds of openssl.
>
ARGH! I do somewhat similar though, yours just sounds harder.
> How does that work for you today? How much code gets rebuilt as you
> prepare the additional mod_ssl builds?
2 OpenSSL builds in srclib, one named openssl and another named
openssl-x (x being 098 or 101). Build Apache and Install. Rename the
OpenSSL folders, change Install folder, rebuild just the few items that
actually link to OpenSSL, Install again. GUI is handy for this since you
can rebuild a single project easily.
This is driven mainly because of mod_php, PHP 5.4 links to OSSL 0.9.8 so
if Apache is built with 1.0.1, it will not start. We offer downgrade
zips for this purpose. mod_fcgid remedies this problem but some people
would rather use mod_php.
> Thanks so much for spending the time!!
No problem, I figured I should give it a whirl.
Gregg
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <gl...@gknw.net> wrote:
> Hi Jeff,
>
> Message 1 of ?
>
>
> On 8/30/2013 5:25 AM, Jeff Trawick wrote:
>
>> Please let me know if you
>>
>> * are waiting for some certain feature (other than near perfection)
>> before you use it
>> * attempt to use it but are slowed down by tool requirements or bad
>> documentation or anything else
>> * attempt to use it but it fails so badly that you leave it in disgust
>> with no desire to report or try to fix anything
>> * try it and it works for you (what cmake backend, what other build
>> characteristics)
>> * etc.
>>
>
> Well, putting on my Apache Haus hat my first impressions are "What a
> nightmare!" :)
> I must say I prefer the more turnkey approach we enjoy these days,
I'm not 100% sure what you mean by the more turnkey approach. I guess that
is putting support libraries under httpd/srclib and having the httpd build
sort of orchestrate putting the libraries together, installing the stuff
httpd cares about, etc?
I'm not familiar with Apache Haus (yet) but it looks like you distribute
binaries for other people and would be scripting your builds anyway for
repeatability.
Perhaps a sample makefile could be shipped with httpd to build third-party
libraries and such, possibly requiring a source layout similar to the
traditional one.
Thoughts on such a makefile or script to tie it all together?
> that said;
>
> I tried this via command line, not the GUI. First creating a batch file
> took quite a bit of the pain out of it. For me, long command lines leave a
> lot of room for typos.
>
Funny, I started with the GUI and filled in the blanks for building a
couple of other packages until I understood what sort of information had to
be provided.
>
> Problems run into;
> WARNING: Target "mod_proxy_html" requests linking to directory
> "C:/buildc/libxml2/win32/bin.**msvc".
> Targets may link only to libraries. CMake is dropping the item.
> WARNING: Target "mod_xml2enc" requests linking to directory
> "C:/buildc/libxml2/win32/bin.**msvc". Tar
> gets may link only to libraries. CMake is dropping the item.
>
I haven't seen anything like that. Can you let me know your build
environment and invocation?
>
> Having to list actual library files is ok for me, but a noob probably
> doesn't know just what lib/s your looking for. MSVC linker has
> /LIBPATH:<path> where if anything, only the directory would need to be
> listed as long as the needed libraies are listed in $(LIBS). What is worse
> here is I see this in the beginningISH;
> -- Found LibXml2: C:/buildc/libxml2/win32/bin.**msvc
> so no it really didn't!
>
> Then:
>
> -- Could NOT find OpenSSL (missing: OPENSSL_LIBRARIES
> OPENSSL_INCLUDE_DIR)
> -- mod_deflate was requested but couldn't be built due to a missing
> prerequisite (ZLIB_FOUND)
> -- mod_ssl was requested but couldn't be built due to a missing
> prerequisite (OPENSSL_FOUND)
> Again, basically same complaint as above. If we only need to give an
> whathaveyou_include_dir, why not a whathaveyou_lib_dir?
>
About dependencies:
For the stuff I tested, cmake automatically finds dependencies that were
installed to the same prefix as the project you're building
(CMAKE_INSTALL_PREFIX). I've been installing zlib, pcre, and libxml2 to
the same prefix that I will place httpd and magic happens.
cmake finds my OpenSSL in a separate place, but probably because I
installed it in the default location. I guess pointing to its library
directory with CMAKE_LIBRARY_PATH and include directory with
CMAKE_INCLUDE_PATH would find it in relatively arbitrary locations, but I
haven't tried that.
I created a bit of pain myself with APR and PCRE: There is no
cmake-bundled FindAPR or FindPCRE, and rather than have the httpd build
worry about apr+apr-util 1 vs apr trunk, or pcre vs pcred, I require the
builder to specify the same sort of information that FindAPR or FindPCRE
would provide.
>
> Some comments I have received off list by folks who will remain unnamed;
>
Thanks for forwarding.
> 1. When I see the readme, there are quite some restrictions. Not sure yet
> if that hurts us much.
>
That presumably is temporary, unless nobody else cares about a cmake-based
build + wants to donate some sweat.
2. I foresee more maintenance/support/issues with cmake, I see it with
> other products using it. It introduces an other dependency.
>
I think that cmake enables more people to build, since there are more build
generators that match the tools that more people have installed. That
certainly increases the number of support issues.
I think that the cmake list is MUCH easier for random httpd/apr developers
to tweak when they add some feature (new source file, new module, etc.)
than editing the project files. I also think that the cmake-based build
can be easier to get comfortable with for Unix-y developers of httpd and
apr, though I suspect it will remain forever more rewarding to just bitch
about Windows and not to any work there.
> 3. Just wondering what is the drive to go the cmake way, I see no that
> issues with the current way.
>
Although I do try to work on Windows from time to time, I am no expert in
building and putting together stuff in the current way. Here is my own
admittedly ignorant understanding of the current build system (please add
corrections):
* I have to do multiple conversions of the project files in svn to run with
the latest Visual Studio stuff
* Manual and/or Visual Studio GUI work is required to build everything
using recent Microsoft tools.
* I don't understand how to get Makefiles that build things the right way
for the latest Microsoft compilers
* There's a high ratio of gorp to critical information in the Windows build
files we maintain in svn, and I feel that I'm going to break something
every time I try to the required new gorp in order to add a file or module
or whatever to the build for Windows.
* People have other build tools on Windows that they want to use, and all
that Visual Studio stuff is essentially useless to them except for trying
to reverse engineer intention out of the generated gorp; certainly not
useful for actually building. (I've only tried "NMake Makefile"-based
builds using a mix of 32-bit, 64-bit, Visual Studio 2010 tools, and Visual
Studio 2012 tools; I haven't tried non-Microsoft compilers yet.)
My build requirements that aren't met with the current system:
* statically linking third-party modules with the server (e.g., including
in libhttpd, editing modules.c)
* fine-grained control over which modules are built and which are loaded by
default
* absolutely no requirement to put support libraries in srclib/*
* ability to build for Windows and various Unixy platforms using the same
basic flow
scons and cmake have been mentioned on these lists in the past as good
tools to solve such issues; after a day of playing with cmake I found it
straightforward enough to use that I kept going. (I never even installed
or otherwise used cmake before late last week.)
> 4. Just puzzling with cmake. Do not know how to start.
>
My suggestion would be to try building pcre and zlib with cmake first,
since it should be much easier to find user experiences/hints/etc. when
things go wrong.
> My personal comments;
>
> PCRE requires CMake, so the one more required tool I see as moot.
>
It is useful to me at least that zlib also supports CMake, so one rapidly
gets up to speed on how to use it without having to rely on this
in-development apr/httpd support to start getting a feel for it.
> This process seems to add a lot of time spent to the build time. This
> process seems much more complex and noobs will probably be bald from
> pulling out their hair by the time they figure it out.
>
All that is needed is a makefile or script to wrap the builds of the
various support libraries, which will help "noobs" as much as the prior
build did.
But really, who is going to use this on Windows? Who are the noobs?
Developers?
>
> On Windows we build all but /extra modules (BuildBin vs. BuildAll with the
> GUI route), would like to see that remain.
>
A couple of defines are needed to establish a specific set of defaults.
For example, a user could set the minimum module enablement to "i" which
means that everything with available prerequisites will be built, but the
LoadModule would be commented out unless a module defaults to a/A (e.g.,
mod_mime) or another define is specified to activate that specific module.
I've punted on that until I've at least sketched in defining prerequisites
for the remaining modules so that a new define like this doesn't cause the
build to blow up.
On Windows we have a good default config loading just what is needed, would
> like to see that remain.
>
I thought that's what we have now ;)
What is missing, or is there just some difference you don't like between
the old build system default and the cmake build system default? Though
there is some rhyme and reason to what is loaded by default, I mainly
wanted to get something out there; play with the exact defaults as you see
fit. (Just make sure to use a instead of A for things that have
prerequisites.)
>
> Why not just look for dependencies where you would find them today
> (source_root\srclib)? We know where everything should be already and would
> really save all the -DTHISnTHAT_INCLUDE/LIB_DIR business. Yes, I understand
> (and one thing I do not like) is that cmake copies & creates files into a
> different directory, with hard coded pointers to everything, but I do not
> see why we should need more that installdir & srcdir. Optional sure, having
> to use those every time, no! I think src_dir/srclib would be a better
> default location than what is there now. One thing if you have to set all
> these in the GUI, that alone could take someone an hour if the have to
> browse to everything (I'd copy/paste paths from Explorer personally).
>
Perhaps I'm misunderstanding something, but installing support libraries to
the same prefix lets cmake find stuff with zero code, and the intention is
to put things in the same prefix anyway, right? If you wanted to put the
sources under srclib but still install to the same prefix it still works?
Somehow I think that a wrapper script/makefiles to put together the
independent builds of the various projects is the missing piece to a lot of
these concerns. I would have thought that different
developers/bundlers/etc. would have their own way to glue things together
that makes sense for them, but perhaps some default is needed.
>
> I've never actually "nmake install" any dependency, it's rather useless on
> Windows. I have to create multiple mod_ssl with different openssl versions
> so installing openssl would limit that. This might help you understand my
> suggestion about dependencies :)
>
I guess with the cmake build of httpd you start with these openssl builds
or installs (whatever it takes for FindOpenSSL to deal with):
\openssl1
\openssl2
\openssl3
You build httpd once using the desired feature set and you specify one of
these openssl trees with the cmake settings
CMAKE_LIBRARY_PATH/CMAKE_INCLUDE_PATH.
Rename that first mod_ssl.so mod_ssl_for_openssl1.so
Build httpd two more times using minimal feature set (save build time),
setting the CMAKE path used to find prereqs to those other builds of
openssl.
How does that work for you today? How much code gets rebuilt as you
prepare the additional mod_ssl builds?
> Obviously I have not built the binaries yet. I need to put it down for
> awhile now but will try more this weekend.
>
> Cheerio and happy Labor Day,
>
> Gregg
>
>
>
Thanks so much for spending the time!!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Noel Butler <no...@ausics.net>.
>
>
> The cmake lists would have to largely duplicate the autoconf tests. I
> have no intention of messing with that, though others are of course
> welcome. So for now: httpd/apr cmake support is only for Windows.
>
and I sure as hell hope it stays that way, cmake is a complete PITA.
I'd go as far as adding "nightmare" into that as well. It's detested by
most admins I know and even many a coder.
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Aug 31, 2013 at 5:42 PM, Steffen <in...@apachelounge.com> wrote:
> Suddenly we have cmake in trunk, is there history to go this way ?
>
I don't know what you mean by "history to go this way".
>
> The primary cmake selling point is cross platform, is it tried on *nix ?
The cmake lists would have to largely duplicate the autoconf tests. I have
no intention of messing with that, though others are of course welcome. So
for now: httpd/apr cmake support is only for Windows.
> With Windows we have "cross VC" namely VC6, VC8, VC9, VC10, VC11 and
> almost official VC12. Quite some work to get it ok on all these.
Are you talking about with the current build system for Windows or the
cmake-based build system? What is the work you're talking about? E.g.,
how do we get compatibility across different VC with the current build
system? I don't see any such work committed to svn. Or do you mean the
conversion process when you are ready to build?
> And be aware that cmake has to be maintained, expect more then the
> current way.
>
Time will tell... What I see is that the cmake list represents the
"intention" of the build very concisely. That should help with maintenance
work, especially since the Windows build system is often updated/maintained
by people who don't have the tools available.
>
> Looked at the cmake in httpd trunk and see there are still some
> limitations/issues.
lots of limitations still; it will take a while to sort those ou
> Not tried yet, figuring out how to start. Anyone knows
> a working command line with options for building with cmake ?
>
I will try to post or commit somewhere a script or makefile that pulls it
all together for multiple support libraries + httpd. I have it now but not
in a form which can be shared.
Do you have a script that builds httpd and a reasonable set of support
libraries starting with a tarball/zipball? I'm not sure what that looks
like with the current build systems.
>
> I have concerns with what looks like the complexity of just building with
> it
> but am going to hold final judgment till I've messed with it. But when I
> see
> the reply of Gregg, then I need first to study the internals of cmake to be
> sure what is going on and how to customize.
>
> Concern is also the flexibility like we have with dsp/vcxproj files. And
> how are the Compile/Link options set, and which uses cmake ?
I don't have any experience with that yet. I see documented options and
experiences of others using cmake with various packages, but until I
actually try it I'll just say "I don't know".
> With the GUI, I
> can set tons of options for example for optimizations, debugging, tracing
> etc. I expect that the current makefile, dsw and dsp files remain, we need
> it to debug/trace, with only cmake we miss a lot.
>
> I am a GUI guy and I state that on Windows the MS tools/stuff should be
> used
> as much as possible, like .dsp and vcproject files. I prefer GUI, it has
> benefit in not just ease of use but also ease of finding and reading the
> errors when problems arise. You can also debug just one module so much
> easier when just rebuilding a project.
>
> Building already for about ten years with .dsp as starting point, done all
> above VC flavors. No issues, for example VC11 runs out of the box with very
> very minor adjustment, it is more that you do the needed steps in a careful
> way.
>
> So wonder why the cmake way is started, are there issues I do not know ?
>
See my previous reply to Greg. Feel free to correct areas of my
understanding which are not correct.
Not surprisingly, I am a script guy. I scriptify my configure options for
Unixy-builds of httpd and support libraries and make adjustments over time
that can be found in version control. I can't fathom going into a complex
GUI like Visual Studio every 6-12 months to try to tweak some build
setting. I just can't remember what to do in a short amount of time.
Product builds that use this stuff on Windows need to scriptify this too.
> I like to help to solve if there are issues. Also with ApacheLounge Forum I
> can conclude see that quite some ppl are building with minor issues. The
> biggest flaw we had till now is with VC11 that APR/iconv was not building,
> but that we solved with a minor adjustment in the iconv make file.
>
> Regards,
>
> Steffen
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Steffen <in...@apachelounge.com>.
Suddenly we have cmake in trunk, is there history to go this way ?
The primary cmake selling point is cross platform, is it tried on *nix ?
With Windows we have "cross VC" namely VC6, VC8, VC9, VC10, VC11 and
almost official VC12. Quite some work to get it ok on all these. And be
aware that cmake has to be maintained, expect more then the current way.
Looked at the cmake in httpd trunk and see there are still some
limitations/issues. Not tried yet, figuring out how to start. Anyone knows
a working command line with options for building with cmake ?
I have concerns with what looks like the complexity of just building with it
but am going to hold final judgment till I've messed with it. But when I see
the reply of Gregg, then I need first to study the internals of cmake to be
sure what is going on and how to customize.
Concern is also the flexibility like we have with dsp/vcxproj files. And
how are the Compile/Link options set, and which uses cmake ? With the GUI, I
can set tons of options for example for optimizations, debugging, tracing
etc. I expect that the current makefile, dsw and dsp files remain, we need
it to debug/trace, with only cmake we miss a lot.
I am a GUI guy and I state that on Windows the MS tools/stuff should be used
as much as possible, like .dsp and vcproject files. I prefer GUI, it has
benefit in not just ease of use but also ease of finding and reading the
errors when problems arise. You can also debug just one module so much
easier when just rebuilding a project.
Building already for about ten years with .dsp as starting point, done all
above VC flavors. No issues, for example VC11 runs out of the box with very
very minor adjustment, it is more that you do the needed steps in a careful
way.
So wonder why the cmake way is started, are there issues I do not know ?
I like to help to solve if there are issues. Also with ApacheLounge Forum I
can conclude see that quite some ppl are building with minor issues. The
biggest flaw we had till now is with VC11 that APR/iconv was not building,
but that we solved with a minor adjustment in the iconv make file.
Regards,
Steffen
Re: will anyone build httpd/apr with cmake on Windows?
Posted by Gregg Smith <gl...@gknw.net>.
Hi Jeff,
Message 1 of ?
On 8/30/2013 5:25 AM, Jeff Trawick wrote:
> Please let me know if you
>
> * are waiting for some certain feature (other than near perfection)
> before you use it
> * attempt to use it but are slowed down by tool requirements or bad
> documentation or anything else
> * attempt to use it but it fails so badly that you leave it in disgust
> with no desire to report or try to fix anything
> * try it and it works for you (what cmake backend, what other build
> characteristics)
> * etc.
Well, putting on my Apache Haus hat my first impressions are "What a
nightmare!" :)
I must say I prefer the more turnkey approach we enjoy these days, that
said;
I tried this via command line, not the GUI. First creating a batch file
took quite a bit of the pain out of it. For me, long command lines leave
a lot of room for typos.
Problems run into;
WARNING: Target "mod_proxy_html" requests linking to directory
"C:/buildc/libxml2/win32/bin.msvc".
Targets may link only to libraries. CMake is dropping the item.
WARNING: Target "mod_xml2enc" requests linking to directory
"C:/buildc/libxml2/win32/bin.msvc". Tar
gets may link only to libraries. CMake is dropping the item.
Having to list actual library files is ok for me, but a noob probably
doesn't know just what lib/s your looking for. MSVC linker has
/LIBPATH:<path> where if anything, only the directory would need to be
listed as long as the needed libraies are listed in $(LIBS). What is
worse here is I see this in the beginningISH;
-- Found LibXml2: C:/buildc/libxml2/win32/bin.msvc
so no it really didn't!
Then:
-- Could NOT find OpenSSL (missing: OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR)
-- mod_deflate was requested but couldn't be built due to a missing
prerequisite (ZLIB_FOUND)
-- mod_ssl was requested but couldn't be built due to a missing
prerequisite (OPENSSL_FOUND)
Again, basically same complaint as above. If we only need to give an
whathaveyou_include_dir, why not a whathaveyou_lib_dir?
Some comments I have received off list by folks who will remain unnamed;
1. When I see the readme, there are quite some restrictions. Not sure
yet if that hurts us much.
2. I foresee more maintenance/support/issues with cmake, I see it with
other products using it. It introduces an other dependency.
3. Just wondering what is the drive to go the cmake way, I see no that
issues with the current way.
4. Just puzzling with cmake. Do not know how to start.
My personal comments;
PCRE requires CMake, so the one more required tool I see as moot.
This process seems to add a lot of time spent to the build time. This
process seems much more complex and noobs will probably be bald from
pulling out their hair by the time they figure it out.
On Windows we build all but /extra modules (BuildBin vs. BuildAll with
the GUI route), would like to see that remain.
On Windows we have a good default config loading just what is needed,
would like to see that remain.
Why not just look for dependencies where you would find them today
(source_root\srclib)? We know where everything should be already and
would really save all the -DTHISnTHAT_INCLUDE/LIB_DIR business. Yes, I
understand (and one thing I do not like) is that cmake copies & creates
files into a different directory, with hard coded pointers to
everything, but I do not see why we should need more that installdir &
srcdir. Optional sure, having to use those every time, no! I think
src_dir/srclib would be a better default location than what is there
now. One thing if you have to set all these in the GUI, that alone could
take someone an hour if the have to browse to everything (I'd copy/paste
paths from Explorer personally).
I've never actually "nmake install" any dependency, it's rather useless
on Windows. I have to create multiple mod_ssl with different openssl
versions so installing openssl would limit that. This might help you
understand my suggestion about dependencies :)
Obviously I have not built the binaries yet. I need to put it down for
awhile now but will try more this weekend.
Cheerio and happy Labor Day,
Gregg