[Gdal-dev] Visual Studio Project Files

[Mateusz Loskot]

Andrey Kiselev wrote:
> 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?

The only way is to use Visual Studio Property Sheet that can be
inherited/overriden.

> 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

In fact, Visual Studio is strongly oriented on project structure made as
project1\project1.vcproj
project1\file.cpp
project1\file.h
...

And if one want to separate sources from project files in some more
sophisticated way, it's a real pain in the ass.
I hardly remember a project where I shouldn't edit VS project files
manually to keep my own project layout of choice and avoid the VS-like
structure.

For example, if I wanted to have relative paths in my project files, like

..\..\subproject1\file.cpp

then I have to edit .vcproj file manually, because Visual Studio does
not provide any option to check that would tell VS to use relative paths.
Or may be I've missed something and I'm a lame VS user :-)

That's why I'd suggest to take a look at the cmake as a solution for
such annoyances.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net