[Gdal-dev] Visual Studio Project Files

[Mateusz Loskot]

Simon Perkins wrote:
> 
> THE ISSUE
> 
> On windows / visual studio, we currently build GDAL using nmake.

Generally, GDAL uses makefile-based building system.
It does not only apply to Windows, but also to Unixes,
even if nmake uses different makefiles format than GNU make on Unix.

> However, particularly with the arrival of Visual Studio 2005, this 
> solution is starting to look a little antiquated.

Sorry, I can't see any special relation between arrival of the VS 2005
and nmake. Both are different tools. AFAIK VS 2005 is not supposed to
replace nmake, as previous VS versions wasn't as well.
As I understand, the issue is about *adding* VS 2005 support but not
with replacing nmake with VS 2005.

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

It is possible to embed a manifest into the final binary when
building with nmake too.
See:
http://msdn2.microsoft.com/en-us/library/ms235591.aspx

Certainly, in order to officially support manifest embedding when
building with VC++ 8.0 compiler, GDAL makefiles need some changes.

What you mean as a "DLL versions" expression?

> PROPOSED SOLUTION
> 
> Create VS 2005 project files, in parallel to the existing nmake 
> files, that allow GDAL to be built within the VS IDE.

IMHO, the overall idea is great, but I also see hassle of the project
files maintenance.

> This should simplify development of GDAL itself under windows by 
> providing easy access to the VS debugger, editor and so forth,

Yes.

> plus it makes it easy for us to create modern compliant GDAL DLLs and
>  executables with embedded manifests.

This issue may be easily solved without VS 2005.
So, I'd say it's not depending on VS 2005 usage.

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

Sorry, but I can't see how this solves the DLL hell problems.
You're still required to keep DLLs together with your executable,
inside common directory, if there are any other GDAL versions
existing in the system, ie. in c:\window folder.

> Finally, the VS debugger will be able to smoothly step from the 
> application into the GDAL source code, simplifying debugging under 
> VS.

That's right.

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

You can have more than one .vcproj files in the same directory.
The VS is a bit dumb and does not allow you to create it that
way, but you have a liberty to edit .vcproj/.sln files to fix
this issue.

> The source code does not have to be in the same directory as the 
> .vcproj files. [...]

That's good.
I'd suggest to keep VS project/solution files outside the source tree
to not to mess the source tree with VS intermediate and other stuff
that's not cleaned when you click Build -> Clean (like, build log, ncb,
suo, and other files).

My suggestion is to have 'build' directory or 'msvc80' and keep all
project files and solution in there, all together or structured in
some subdirs. For example:

<gdal>\msvc80\gdal.sln
<gdal>\msvc80\frmts\<library>\<library>.vcproj
<gdal>\msvc80\ogr\ogr.vcproj
<gdal>\msvc80\ogrsf_frmts\<library>\<library>.vcproj
.etc.

where
<gdal> is a root directory of the GDAL sources
<library> is a placeholder for library name, a driver

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

Exactly, that's what I'm talking about a few lines above. Great.
One note, the AFAIK we're going to use Visual C++ only,
so visual_studio name may seem to verbose.

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

I'd suggest to use Visual Studio Property Sheet which can be edited
using Property Manager.
Then all project files can inherit from common property sheet.
I've tested this approach when developing Visual C++ project files for
SOCI library project and it works well.
You can define all paths and predefine macros/env variables
that user can be asked to fill with value.
For example, PROJ4_DIR and user will need to fill it with appropriate path.

Another option is to use command line, provide .bat script to set all
environment and then build.bat which will build GDAL calling VS from
command line (see FDO build system, http://fdo.osgeo.org/)
But as I understand it's not the case here.

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

Personally, instead of playing VS project files and solution,
I'd try to see if cmake may be helpful here.
cmake uses CMakeLists.txt files (something like makefile) and then
generates Visual Studio project files on Windows and Makefile files for
GNU make on Unix.
See: http://www.cmake.org

Theoretically (I've not used it on Windows yet), cmake would be a
solution to keep portable meta-build system that can use native build
systems for particular platform: Visual Studio on Windows and GNU make
on Unix.
The build system maintenance would be much more easier: "maintain once
and support two".
Recently, one user posted cmake config for GEOS on the GEOS' list.
I played with it a bit and it seems to be very nice, clean and easy to
maintain and powerful.

http://geos.refractions.net/pipermail/geos-devel/2006-September/002552.html
http://geos.refractions.net/pipermail/geos-devel/2006-September/002553.html

So, may be cmake is worth to look at.

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