On Sun, Sep 1, 2013 at 3:19 PM, Tom Donovan <[email protected]>wrote:
> 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. > Does this address your concern to any great extent? * Putting the dependencies in srclib means you'll install them to the same prefix. * Installing things to the same prefix allows them to be easily found due to that (instead of due to living in srclib), and having them found due to common prefix helps users like you that like dependencies stored in srclib as well as users like me that want everything clearly separate. (Imagine building 30 different open source projects, and maybe httpd needs pcre and libxml2 and openssl and so forth, but a lot of other projects need them to, so it doesn't make sense for them to be subservient to httpd.) * We're missing the Makefile.win replacement that ties everything together. > > 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 guess I'm stubborn, but I want to see how far I can get by installing the packages to a common prefix, just like on Unix. I don't yet see why one package has to own the installation of another package's binaries. We'll see. At any rate, it seems to me that this is a job for the Makefile.win replacement??? > > 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. > Re: LIBXML2_ICONV_INCLUDE_DIR... This is a very muddy concept :( libxml2 on Windows may or may not need GNU iconv, depending on how you configure libxml2 (I've built both ways). LIBXML2_ICONV_LIBRARIES and LIBXML2_ICONV_INCLUDE_DIR essentially mean: If your build of libxml2 needs iconv, then set these to the name of the iconv library and the directory with iconv include files. If your build of libxml2 does not need iconv, leave them unset. These could be set automatically by running a small configure test to see if iconv is needed, and in turn looking in CMAKE_INSTALL_PREFIX for iconv. Some of us need to build everything with no LGPL stuff anywhere, hence my support (however crude) for building the different flavors of libxml2. > > I'll keep at it - and thanks again for all your hard work. > > Regards, > -tom- > > > > > -- Born in Roswell... married an alien... http://emptyhammock.com/
