On Thu, Aug 22, 2013 at 6:47 PM, Tom Donovan <donov...@bellatlantic.net>wrote:
> On 08/22/2013 04:55 PM, Jeff Trawick wrote: > > On Thu, Aug 22, 2013 at 10:49 AM, Tom Donovan <donov...@bellatlantic.net > > <mailto:donov...@bellatlantic.net>> wrote: > > > > On 08/20/2013 03:47 PM, Jeff Trawick wrote: > > > I plan to spend some time tilting at that windmill starting later > this week, for the purposes of > > > getting a flexible build on Windows. Enough time to get something > working? Dunno :( > > > > > > -- > > > Born in Roswell... married an alien... > > > http://emptyhammock.com/ > > > > I gave it a try last March, but I never found the time to follow up > and finish it. > > I was able to build apr and httpd (trunk) on Windows7. > > > > My Windows-only CMakeLists.txt files for both apr & httpd, along > with some notes, are at: > > > > http://people.apache.org/~tdonovan/cmake/HTTPD_CMake.zip > > > > Please help yourself to anything here which is useful to your effort. > > > > -t- > > > > > > Hi Tom, > > > > By chance did you experiment with FindOpenSSL, FindZLIB, etc.? > > > > -- > > Born in Roswell... married an alien... > > http://emptyhammock.com/ > > Hi Jeff, > > I looked at them briefly, but no, I didn't experiment much. > > On Windows, those CMake modules seem to have an impossible job. There is > really no "standard" > location on Windows for OpenSSL, Zlib, et. al. - especially since headers > are needed in addition to > the runtime libraries. These modules pose a risk of finding some > unrelated OpenSSL or Zlib library > which might have been built with a different Windows compiler, and might > use a different C runtime > library. > > I used my own rules instead to locate the eleven prerequisites that APR or > HTTPD might use on > Windows. The rules I made for PCRE, ICONV, LUA, LIBXML2 (or EXPAT), ZLIB, > OPENSSL, SQLITE3, PGSQL, > MYSQL, ORACLE, and BDB (Berkeley DB) were: > > * If the symbol is defined on the CMake command-line, it points to the > directory that the > prerequisite is installed in. i.e. the directory containing bin, include, > and lib subdirectories. > > e.g. > CMAKE -D SQLITE3=C:/work/sqlite3 -D PCRE=D:/build/pcre -D > ICONV=C:/work/libiconv ... > > * If the symbol is not defined, a check is made for directories named: > > srclib\pcre, srclib\libiconv, srclib\lua, srclib\libxml2, srclib\zlib, > srclib\openssl, > srclib\sqlite3, srclib\postgresql, srclib\mysql, srclib\oracle, or > srclib\berkeleydb. > > * If the symbol isn't defined and the srclib\XXX subdirectory doesn't > exist - then the > prerequisite is not present. > > -tom- > > Thanks... I haven't gotten nearly far enough with optional prerequisites to judge FindXXX vs. custom logic. For now, this setting before starting cmake has been enough to allow FindExpat and FindLibXml2 to work: set CMAKE_LIBRARY_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\lib;c:\Users\Trawick\Expat2.1.0\Bin; set CMAKE_INCLUDE_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\include;c:\Users\Trawick\Expat2.1.0\Source\lib I'll see how far that gets me :) Another difference in my direction, tied up in the same cmake logic, is not copying some other project's DLLs around, such as into the apr (or httpd for that matter) install directory. Theoretically it should just work by choosing the same install prefix for each project. Otherwise the user would have to update PATH. I fear that the magic to avoid that hides the steps that might be necessary when they later update one particular support library. A bundler that delivers a complete application package and can't get the cmake install logic in all the support library packages to agree would just copy the DLLs to the desired place in their own scripts. Either of these choices may fall by the wayside because of what lurks right around the corner. -- Born in Roswell... married an alien... http://emptyhammock.com/
