[Gdal-dev] Visual Studio Project Files

[Simon Perkins]

On Thu, 14 Sep 2006 13:47:39 +0400, "Andrey Kiselev"
<dron at ak4719.spb.edu> said:
> On Wed, Sep 13, 2006 at 11:06:00AM -0600, Simon Perkins wrote:
> > 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.
> 
> Simon,
> 
> That all looks pretty complicated to maintain. Is there a way to include
> in project files the list of file paths and include parameters like it
> is done in the current makefiles? Otherwise it gets too complicated even
> to 
> add a single new file to the project. If we will found a way to keep the
> file lists and configuration parameters separate from the project files
> there will be no problem to add them to GDAL. Without such separation
> there should be the one who will regularly update project files.

Hi Anrey,

Which bit do you mean is complicated? The separate directory of Visual
Studio files? Or the separate project files for each built component? Or
maintaining configurations etc? Under VS 2005, I think it's possible to
have project files inherit from one another, so I think that it should
be possible to put all the common information in one place. If you add a
file to a component, you would have to add that file to the relevant
project file (no wildcards or things like that), but that shouldn't be a
huge maintenance headache. Anyway, I'll take a look to see what's
possible, and when I have something more concrete we can decide whether
to include it in the GDAL source tree or distribute it as an unsupported
contributed extra.


Thanks to Roger and others for the 2003 project files which should
provide a good starting point.

Cheers,

Sy