On 09/01/2013 09:55 AM, Jeff Trawick wrote: > On Sun, Sep 1, 2013 at 9:37 AM, Guenter Knauf <[email protected] > <mailto:[email protected]>> 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-
