[Gdal-dev] Visual Studio Project Files
sy at perkins.net
Wed Sep 13 13:06:00 EDT 2006
Matt Hanson and I had a thread going in which the subject of Visual
Studio Project files came up. I didn't get any comments on that and
figured the details might have been lost in the noise, so here's a
second attempt to elicit some feedback...
On windows / visual studio, we currently build GDAL using nmake.
However, particularly with the arrival of Visual Studio 2005, this
solution is starting to look a little antiquated. In particular, the
introduction of manifests and tighter coupling to DLL versions has made
it a little harder to build GDAL and have it work smoothly with other
Visual Studio projects. Problems with not having the manifests embedded,
and clashes between debug and non-debug libraries seem to have greatly
increased under VS 2005.
Create VS 2005 project files, in parallel to the existing nmake files,
that allow GDAL to be built within the VS IDE. This should simplify
development of GDAL itself under windows by providing easy access to the
VS debugger, editor and so forth, plus it makes it easy for us to create
modern compliant GDAL DLLs and executables with embedded manifests. In
addition, applications that use GDAL that are built using visual studio
can link to GDAL simply by referencing the GDAL project files, which
should clean up a lot of problems with DLL versions etc. Finally, the VS
debugger will be able to smoothly step from the application into the
GDAL source code, simplifying debugging under VS.
The Visual Studio IDE requires that each individual DLL, executable etc,
be treated as a separate "Project" within a larger "Solution". The
.vcproj files defining individual projects have to live in their own
sub-directories - you cannot have more than one .vcproj file in the same
directory (or at least, I haven't found an easy way of doing this). The
source code does not have to be in the same directory as the .vcproj
files. The acutal executables, libraries, etc are built in Debug and
Release sub-directories of the .vcproj directories. Note that other VS
applications that depend on GDAL do not have to know about this level of
detail - they simply reference the .vcproj file.
Given this structure it would be awkward to fit the VS project files in
the same directories as the existing source code and makefiles. Instead,
it would probably make more sense to create a separate hierarchy of VS
project files that cross references to the GDAL source code. So, we
would create a top level directory with gdal, called something like
gdal/visual_studio, and then create separate project subdirectories
under that for each executable and DLL that we want to build. Those
project files would then refer across to source code in other GDAL
directories. We would set things up so that relative paths were used.
One issue is how to handle configuration related activites. Currently,
GDAL is configured for Visual Studio through manual editing of the
nmake.opt file. This both determines what optional components get built,
and where the external libraries and header files that GDAL needs can be
found. VS supports a degree of user configurability, but we would have
to look carefully at how this could be made to work with project files
In particular, we need to try to separate congifuration files that are
going to be different for every user, and the common build files that
users will want to update from CVS.
So, what d'yall think? Is it necessary? Would it be useful? Any ideas
about this could be implemented most effectively? Anyone done any work
on this already that they want to share? I would be happy to take a
first stab at this. Should this be written up as an official RFC? How do
I do that?
More information about the Gdal-dev