httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: will anyone build httpd/apr with cmake on Windows?
Date Sat, 31 Aug 2013 21:41:12 GMT
On Sat, Aug 31, 2013 at 3:53 PM, Gregg Smith <> 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

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

* 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
* 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?

> 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

> 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):


You build httpd once using the desired feature set and you specify one of
these openssl trees with the cmake settings

Rename that first

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

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

View raw message