On Sat, Aug 31, 2013 at 5:42 PM, Steffen <[email protected]> wrote:
> Suddenly we have cmake in trunk, is there history to go this way ? > I don't know what you mean by "history to go this way". > > The primary cmake selling point is cross platform, is it tried on *nix ? The cmake lists would have to largely duplicate the autoconf tests. I have no intention of messing with that, though others are of course welcome. So for now: httpd/apr cmake support is only for Windows. > With Windows we have "cross VC" namely VC6, VC8, VC9, VC10, VC11 and > almost official VC12. Quite some work to get it ok on all these. Are you talking about with the current build system for Windows or the cmake-based build system? What is the work you're talking about? E.g., how do we get compatibility across different VC with the current build system? I don't see any such work committed to svn. Or do you mean the conversion process when you are ready to build? > And be aware that cmake has to be maintained, expect more then the > current way. > Time will tell... What I see is that the cmake list represents the "intention" of the build very concisely. That should help with maintenance work, especially since the Windows build system is often updated/maintained by people who don't have the tools available. > > Looked at the cmake in httpd trunk and see there are still some > limitations/issues. lots of limitations still; it will take a while to sort those ou > Not tried yet, figuring out how to start. Anyone knows > a working command line with options for building with cmake ? > I will try to post or commit somewhere a script or makefile that pulls it all together for multiple support libraries + httpd. I have it now but not in a form which can be shared. Do you have a script that builds httpd and a reasonable set of support libraries starting with a tarball/zipball? I'm not sure what that looks like with the current build systems. > > I have concerns with what looks like the complexity of just building with > it > but am going to hold final judgment till I've messed with it. But when I > see > the reply of Gregg, then I need first to study the internals of cmake to be > sure what is going on and how to customize. > > Concern is also the flexibility like we have with dsp/vcxproj files. And > how are the Compile/Link options set, and which uses cmake ? I don't have any experience with that yet. I see documented options and experiences of others using cmake with various packages, but until I actually try it I'll just say "I don't know". > With the GUI, I > can set tons of options for example for optimizations, debugging, tracing > etc. I expect that the current makefile, dsw and dsp files remain, we need > it to debug/trace, with only cmake we miss a lot. > > I am a GUI guy and I state that on Windows the MS tools/stuff should be > used > as much as possible, like .dsp and vcproject files. I prefer GUI, it has > benefit in not just ease of use but also ease of finding and reading the > errors when problems arise. You can also debug just one module so much > easier when just rebuilding a project. > > Building already for about ten years with .dsp as starting point, done all > above VC flavors. No issues, for example VC11 runs out of the box with very > very minor adjustment, it is more that you do the needed steps in a careful > way. > > So wonder why the cmake way is started, are there issues I do not know ? > See my previous reply to Greg. Feel free to correct areas of my understanding which are not correct. Not surprisingly, I am a script guy. I scriptify my configure options for Unixy-builds of httpd and support libraries and make adjustments over time that can be found in version control. I can't fathom going into a complex GUI like Visual Studio every 6-12 months to try to tweak some build setting. I just can't remember what to do in a short amount of time. Product builds that use this stuff on Windows need to scriptify this too. > I like to help to solve if there are issues. Also with ApacheLounge Forum I > can conclude see that quite some ppl are building with minor issues. The > biggest flaw we had till now is with VC11 that APR/iconv was not building, > but that we solved with a minor adjustment in the iconv make file. > > Regards, > > Steffen > -- Born in Roswell... married an alien... http://emptyhammock.com/
