On Tue, Sep 3, 2013 at 8:35 PM, Ben Reser <[email protected]> wrote: > On 9/1/13 4:50 AM, Jeff Trawick wrote: > > *Doesn't it take more than one level of Visual Studio to get it into > something > > that the most recent versions will use? > > I don't think going through more than one version of Visual Studio helps, > at > least not if you're trying to build with Visual Studio 2012. > > Converting with Visual Studio 2010 can't be done from the command line, it > has > to be done in the GUI. Visual Studio 2012 can convert everything from the > command line. I can't say that I've done anything older than that though I > know I've had a working 2008 configuration at one point but I never > scripted it > so I don't remember the steps. > > The major problems I've seen after conversion are shared intermediary build > directories, manifest files, and TargetName. Take a look at the > build_httpd > subroutine in this script for details of the hoops that have to be jumped > through: > > https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/build-svn-deps-win.pl
too bad about all the httpd/apr build hacks, but still a nice example of a high function workflow that can be implemented on top of general build capabilities I don't think there's much appreciation yet of the sheer practicality of more individuals being able to implement a workflow that makes sense for them when the basic build just works and little effort is spent hacking it for one set of build tools or another. (That's not to say that there shouldn't be some typical workflow implemented in a makefile/script shipped with httpd.) > > > All of these basically come down to Visual Studio behaving differently > than in > previous versions. The problem with the existing build system is that > there's > no way to correctly fix most of this. Anyone trying basically has to have > all > the tool chains all the way up from VC6 to test with. > > For all practical purposes it is impossible to build httpd on modern tool > chains unless you spend a lot of time googling and looking for help posted > on > various forums. Some of these issues may be something that Windows > developers > are familiar with and just know how to fix off hand, but in my experiece I > spent a ton of time trying to figure all of this out. > > So in my opinion the real failing of the existing system is that the same > work > is being done over and over and over again. Nobody can show up and say > "Ohh > VC2012 breaks due to this change, here's the patch" and then have the patch > applied to the build system so that nobody else has to deal with that > problem > again. > > The benefit of CMake is that even more of that work can be done upstream by > CMake and we don't necessarily even have to deal with all of it. There > will > always be some, but at least your conversion support is now being > supported by > someone that actually cares about it (no sorry Microsoft's support for > conversion doesn't count). > > The cost of course is paid by the people who have already jumped through > the > hoops and expended the energy to figure out how to build with the current > system. These people now have to figure out how to build with CMake which > is > an extra step for them. > > I suspect when all is said and done though that everyone will end up > better off > though. > -- Born in Roswell... married an alien... http://emptyhammock.com/
