On Thu, Aug 22, 2013 at 3:22 PM, <traw...@apache.org> wrote:

> Author: trawick
> Date: Thu Aug 22 19:22:03 2013
> New Revision: 1516542
>
> URL: http://svn.apache.org/r1516542
> Log:
> 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.
>
> Added:
>     apr/apr/trunk/CMakeLists.txt   (with props)
>     apr/apr/trunk/include/apr.hwc   (with props)
> Modified:
>     apr/apr/trunk/CHANGES
>
> 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
#   + APR_POOL_DEBUG
#   + APU_DSO_MODULE_BUILD
#   + APU_HAVE_GDBM
#   + APU_HAVE_NDBM
#   + APU_HAVE_DB
#   + APU_HAVE_PGSQL
#   + APU_HAVE_MYSQL
#   + APU_HAVE_SQLITE3
#   + APU_HAVE_SQLITE2
#   + APU_HAVE_ORACLE
#   + APU_HAVE_ODBC
#   + APU_HAVE_CRYPTO
#   + APU_HAVE_OPENSSL
#   + APU_HAVE_NSS
#   + APU_HAVE_COMMONCRYPTO
#   + APU_HAVE_ICONV
#   + 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...
http://emptyhammock.com/

Reply via email to