[Gdal-dev] GDAL and VS 2005 (Was: Creating VRT datasets)

[Simon Perkins]

Matt Hanson wrote:
> Sy, you are right about debug mode being /MDd, I was messed up I thought /MD was debug.   Regardless, it did fix things.  Compiling my proj in Debug mode (/MDd switch) generated the error.   When I switched to /MD it worked.    The thing I'm confused about is why it worked for the release version of GDAL.
>   

The release version of GDAL? If you're talking about the two lines of 
compiler options in nmake.opt that you can choose between, they both 
specify /MD. The only difference is that the "debug" line turns off 
optimization and generates a debug symbol file (a .pdb file).

So, are you saying that with GDAL compiled with the /MD switch, and 
optimization on, your application, compiled in debug mode within the 
IDE, worked fine? So many combinations to consider...


On a related note, I wonder whether some of our problems are cause by 
nmake. With every new version of visual studio, I can't help but feel 
that it's a  bti of a dinosaur. For instance, consider the problems with 
manifests. Maybe we should be looking at creating a visual studio 
project file or two for building gdal? Has anyone done this?

If GDAL was built using a proper .vcproj file, then other applications 
built using VS could "reference" that project in an easy way.

One slightly annoying thing I've encountered in the past when converting 
makefile projects into Visual Studio is that VS divides a complete 
"Solution" (i.e. the GDAL package) up into individual "Projects" (i.e. 
the final executables, DLLs etc), and then appears to insist that each 
the .vcproj file associated with each project lives in it its own 
directory. In contrast the GDAL directory organization builds several 
libraries and executables from the same directory, .e.g gdal/apps. In a 
port that I'm woking on now, I've ended up moving all the source code 
related to different executables into their own sub-directories. I 
wouldn't want to emabrk on such a major change in GDAL.

Now, note that the vcproj files do not have to be in the same directory 
as the source code files, so one solution is to create a separate 
hierarchy of  .vcproj files, with one executable / DLL to each 
directory, that then refers across to the GDAL source files. This 
preserves the existnig structure of the source code, but has the 
unfortunate side effect of separating source code from the associated 
.vcproj files.

Anybody had experience with this task or have any other thoughts?