Re: autoconf in pure MSVC environment?

[Austin Schutz]

On Tue, Sep 07, 2004 at 12:55:30PM -0700, Brandon J. Van Every wrote:
> > > 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>.
> 


        Forgive me if I'm not understanding your goal, but visual studio
supports the use of external commands. They seem to be necessary when using
e.g. masm to compile assembly programs, which VS doesn't seem to support
directly any more. So, it seems intuitive that you should be able to use VS to
compile using configure & make, perhaps with a little bit of batch file
coaxing.
        That would require a bit of setup and maybe even the installation
of supporting tools such as parts of cygwin, but it doesn't seem unreasonable
to have _developers_ install that stuff, as opposed to end users. Developers
are generally a little more capable and flexible with fooling around with their
environment to make tools they want to use work (see note about masm).

        So then you are lastly left with translating compile options to work
with your compiler/linker. That doesn't seem in and of itself like an enormous
problem. Probably a couple hours of perl hackery and you could have something
that would work reasonably well for the important options.

        Am I missing something? I don't think you'll achieve autogenerated
.sln files, but that doesn't really seem like your goal.

        Austin