On Thu, Aug 22, 2013 at 3:22 PM, <trawick@apache.org> wrote:
Author: trawick
Date: Thu Aug 22 19:22:03 2013
New Revision: 1516542

URL: http://svn.apache.org/r1516542
Add experimental cmake-based build system for Windows.

include/apr.hwc is almost exactly the same as apr.hw; it uses
variables for cmake-time feature selection so that cmake
can easily generate apr.h.

    apr/apr/trunk/CMakeLists.txt   (with props)
    apr/apr/trunk/include/apr.hwc   (with props)

Modified: apr/apr/trunk/CHANGES
URL: http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1516542&r1=1516541&r2=1516542&view=diff
--- apr/apr/trunk/CHANGES [utf-8] (original)
+++ apr/apr/trunk/CHANGES [utf-8] Thu Aug 22 19:22:03 2013
@@ -1,6 +1,8 @@
                                                      -*- coding: utf-8 -*-
 Changes for APR 2.0.0

+  *) Add experimental cmake-based build system for Windows.  [Jeff Trawick]

Note the list of current bugs/deficiencies in CMakeLists.txt, a lot of which are handled by Tom's CMakeLists.txt which he posted a couple of hours ago.  I plan to pull in his stuff as I can understand/test it, but feel free to pitch in :)

From CMakeLists.txt:

# . Fix problem where srcdir/include/apr.h (if it exists) is found before builddir/apr.h
#   (and similar for apu_want.h)
# . Document example 32-bit and 64-bit Windows builds using NMake
# . Build and optionally run gen_test_char
# . Build apr_app.c into libapr-2 properly (what about apr-2.lib?)
# . Options for remaining features, along with finding any necessary libraries
#   + APU_USE_LIBXML2 (sketched in, but not working)
# . Support static *or* shared build of Expat
# . Some easier way to run the test suite (not just testall.exe)
# . All the other stuff Jeff doesn't know about yet

If anyone cares about this, the best way to help in the very short term is to add stuff you know of that I've missed from the bug/missing-feature list.  Then, of course, pull up your shirt sleeves and pitch in.

Apologies for the programming style in CMakeLists.txt, which is a lot different than the one Tom had; if you've ever seen the one distributed with PCRE you might guess (correctly) that I had mainly looked at that one before starting this one for APR.

I suggest the following as the roadmap for Windows build support:

APR Trunk/2.0:

As soon as multiple developers can use cmake successfully and build bugs have been resolved, axe any support for specific MS compilers/IDEs/whatever.

(autoconf-/MinGW-based build support remains; I happen to feel very productive using that for development/debugging, though I don't see enough interest to finish the work to fully support that for end user builds; no knowledge here of autoconf-Cygwin-based build support for Windows other than that there are various pieces of configure code to support that)

Current stable branches of apr 1.x/apr-util 1.x:

Add cmake-based build support as an additional option "before long."

apr-iconv?  I'd rather not think about that for now.  (Somebody remind me which httpd features need that on Windows and maybe I'll be motivated.)

Implied or required layout of projects:

Traditional builds of httpd/apr*/etc. typically put ASF and other support libraries in the tree under httpd/srclib, and in fact some unexpected httpd+Windows dependencies on apr essentially required that.  I haven't figured out yet if any of that is baked into Tom's cmake work for apr/httpd, or if srclib/<SUPPORTLIB> is simply the default.  I have ZERO interest in touching such a setup personally, and at present the apr install will set up private_include/ alongside include/ to work around the httpd desire for such files.  (I guess there are any number of other dependencies I don't know about/remember :()

Thanks in advance for the *.

Born in Roswell... married an alien...