A preamble, in the hope of conditioning further responses. I think we could go back and forth about cultural isses until the cows come home, but I'd be more interested in focusing on the feasibility of the problem, as stated in the subject line. Bob Friesenhahn wrote: > Brandon J. Van Every wrote: > > > > you might need 3 #ifdefs. In fact, my idea about using > > Autoconf is to > > determine if the dependencies are so minor that they *can* > > in fact be dealt with trivially. > > Most package configure scripts only test for functions which are not > reliably available across Unix systems. They assume that baseline > Unix/POSIX functionality exists. This means that an inspection of an > existing configure script will not indicate how difficult the > associated package will be to port to Windows. Interesting point I hadn't considered. Nevertheless, a configure script *does* march through a number of points of failure quickly. For instance, is Library X available on the system? Ok, get that working. Autoconf under pure MSVC doesn't have to solve everything. It just has to substantially reduce the amount of work required to evaluate the portability of a project. Also, I disagree that 'most packages' assume a baseline of Unix/POSIX functionality. The last 2 game projects I ported from Mingw to MSVC were already quite platform neutral, there was little remaining to "put them under the table," so to speak. Even if you are correct regarding statistics, it's not relevant. What's relevant is the specific project to be ported, not the general case. Projects are self-selecting in this way. I'm not trying to port *everything* to MSVC, I'm trying to port what's already fairly feasible to port. > > To get real duplicability of build environment, and real > > vetting by a > > lot of Windows developers, code has to be built natively under MSVC. > > What version of MSVC? 6.0 != 7.0 != 7.1 Since you brought that up, VC7.1. The plethora of VCs is a related problem in open source development. Many open source projects have made it to the point of providing a VC6 build, but haven't moved on to what native Windows developers consider a modern compiler. Availability of the compiler isn't the issue, as Microsoft provides the compiler sans Visual Studio IDE for free: http://msdn.microsoft.com/visualc/vctoolkit2003/ Rather, it's inertia, desire to support old libraries and tool chains, amount of work of moving forwards, stacked library dependencies, lack of volunteer energy or enthusiasm for Windows platform issues, etc. Not all pushes forwards in MSVC-land are bad, BTW. C++ STL compliance improved tremendously from VC6 to VC7. Standard library is forced in VC7.1, i.e. must switch from <iostream.h> to <iostream>. > From this standpoint, a Windows build scheme based on the GNU Auto* > tools is much more stable and not subject to "upgrade hell" since it > depends on tools which have had their interfaces defined for the past > 25 years. But it is not mainstream reality. I think one of the engineering dimensions we all should be dealing with, is reality. In practice, the vast majority of the Windows world uses MSVC. You can either see the goal of open source as "toppling" Microsoft and all of these people, or in terms of making it easier for people to do what they actually want to do. You won't get open source culture on Windows by insisting that it has to become UNIX. The past 25 years are also not the future. In the OCaml community we've got, like, 10 different projects trying to improve upon GNU Make and GNU Autoconf. The main advantages of Autoconf / Make are that they're widespread, battle-tested, and familiar, not that they're ideal. > Windows isn't a second class citizen? ;-) Thanks for making my point. There are at least 3 possible world views: - UNIX is what matters - Windows is what matters - platform neutrality is what matters I am of the "neutrality" camp. I dislike all OSes, as they only get in the way of game, 3D graphics, and AI problems. When my back is put against the wall, I will defend the "Windows" camp, because I'm trying to develop commercial games. Windows is the dominant market for that. I'm stuck with that platform for the forseeable future. I want as little rigamarole to deal with my problems as possible. Cheers, www.indiegamedesign.com Brandon Van Every Seattle, WA "We live in a world of very bright people building crappy software with total shit for tools and process." - Ed Mckenzie _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
