On 23.06.2011 23:36, William A. Rowe Jr. wrote: > On 6/23/2011 4:30 PM, Igor Galić wrote: >> Hey guys, >> >> apr and apr-util are now for most Unix flavours except Solaris >> on ci http://ci.apache.org/builders/ >> >> Gavin would like to proceed with the Windows build next but it >> appears that the current trunk needs VC6 and doesn't work out >> of the box on VC10 - if at all. >> >> http://apr.apache.org/compiling_win32.html seems to support >> that suspicion. Is this the status quo or just a lacking on >> the documentation front? > Trunk doesn't work out of the box, because we've avoided checking in > any VC6-exported .mak/.dep files; these are likely to stay in flux > as 2.0 is further polished and cleaned up. Every .dsp commit would > need to be chased by a (louder) .mak commit, and the dependencies > can also remain in flux. Alternately, there is cmake logic here > already that should work, but I haven't been actively doing anything > with it. > > The right answer is to drop .dsp, and figure out a better makefile > representation/generator for msvc, and perhaps offer some vcproj > based solution for developers who are exploring the apr API. It's > something I had given thought to already, and will spend cycles on > this once I've cleaned up my currently overfilled plate a bit. For > anyone who wants to beat me to it, my initial thought is to borrow > from the subversion project. And for ./configure detection, note > that vbs windows scripting host is available out-of-the-box all the > time on supported win32 OS's (something that wasn't true when we > last considered and discarded the idea of leveraging it).
Subversion has a build setup that does exatly what you're describing, i.e., generates almost any flavour of MSVC project files (and Unix makefiles) from a generic source tree description. Sure it's not SCons, but I don't see the SCons build working on Windows anyway. So why would APR not want to adopt a build system that's been working just fine for a decade? -- Brane
