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

Matt Hanson mhanson at photon.com
Tue Sep 12 14:10:47 EDT 2006


Ah, I guess you are right - GDAL always uses /MD.   I had to switch my project from /MDd to /MD as well when compiling it in Debug mode.
 
I have not compiled a release version of GDAL, but will have to at some point.
 
The whole manifest issue is certainly annoying, and confusing.   The whole idea of having to have a separate manifest file for DLL's seems like not just one step back, but 20 steps back.  Well actually you don't *have* to have a separate manifest file but I don't know how to change GDAL's nmake.opt to embed the manifest in the DLL.
 
A VS Solution file would be a great help - I think the way to handle that to minimize impact on GDAL is just to have a separate VS folder where ALL of the solution and vcproj files can reside, referencing back to the dir structure of GDAL.    
 
Is there some way to specify a file from the VS compiler options so we could just reference nmake.opt from within the VS Solution ?
 
 

________________________________

From: Simon Perkins [mailto:sy at perkins.net]
Sent: Tue 9/12/2006 1:17 PM
To: Matt Hanson
Cc: gdal-dev at lists.maptools.org
Subject: Re: [Gdal-dev] GDAL and VS 2005 (Was: Creating VRT datasets)



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?









More information about the Gdal-dev mailing list