[Gdal-dev] Visual Studio Project Files

[Craig Miller]

I'm in favor of them being officially supported.  There is already an
unofficial set available that works quite nicely (under VS2003 anyway).

--Craig 

-----Original Message-----
From: gdal-dev-bounces at lists.maptools.org
[mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of Simon Perkins
Sent: Wednesday, September 13, 2006 10:06 AM
To: gdal-dev at lists.maptools.org
Subject: [Gdal-dev] Visual Studio Project Files

Hi,

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...

THE ISSUE

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.

PROPOSED SOLUTION

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.

PROPOSED IMPLEMENTATION

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?

Cheers,

Sy
_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev