[Gdal-dev] Visual Studio Project Files

[Mateusz Loskot]

Simon Perkins wrote:
> On Tue, 19 Sep 2006 19:10:26 +0200, "Mateusz Loskot" 
> <mateusz at loskot.net> said:
>>>> 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.
> 
> 
> [...] so my question was whether it would be worth migrating to, or
> adding, an IDE based set of script (project files).

MIHO, it's worth, if there are users interested to keep project
files up to date.


>> What you mean as a "DLL versions" expression?
> 
>> 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.
> 
> The main issue I'm referring to is the binding to the microsoft
> runtime libraries. I've found that in building various DLLs and
> executables in different ways, e.g. my application using the IDE,
> GDAL using nmake, and, say, some library that GDAl depends upon using
> the IDE,

There should be no differences between DLLs when building programs using
Visual C++ run from command line or from IDE. In both cases the same
compiler and SDK is used.

> I've seen problems with MSVCR80.dll not found messages that I didn't
> see prior to VS 2005. When other people recently started posting
> similar errors on this list, I fiigured there might be a problem...
> It seems that there's no longer a single MSVCR80.dll file - instead
> the system DLLs all have "strong names" referenced in the embedded
> manifests.

Not exactly.
There is the single file of this DLL but the problem was likely on the
GDAL side.
The MSVCR80.dll could not be found by GDAL because GDAL is not build
with the manifest, embedded or as an external file.
Simply, the "MSVCR80.dll not found" issue is usually caused by following
reasons:
1. msvcr80.dll library is not present in the system -> this is a bug VC++
2. exe/dll has not been compiled with manifest support


>> 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.
> 
> 
> Now THAT is a very interesting suggestion! I've used cmake as a user 
> before (e.g. with the VXL libraries), but have never set up scripts
> for it. I was reluctant to suggest a unified cross platform build
> solution after so much effort has gone into tuning the UNIX and
> makfile.vc files over the years, but that could be a better solution
> that trying to maintain multiple sets of Visual Studio project files
> in addition to the UNIX and nmake makefiles.
> 
> Anyone here had much experience writing build scripts using cmake for
>  unix and windows? How is it?

I wrote a few small cmake scripts for testing purpose only
and I like it.
I think someone from the KDE dev team should be able to tell you more
about some experiences because KDE has switched to cmake already:
http://lwn.net/Articles/188693/

> I've used a different cross-platform system, SCons, in the past, but 
> I've found that it's still necessary to do a lot of special hacking
> for windows and linux, plus SCons does not create native build
> scripts for different platforms - it insists on being in control
> itself during every build. I've concluded that this is perhap not the
> best plan. Maybe I'll take a look at cmake then...

Another powerful option is Jam used by Boost libraries and it supports
rich set of toolsets, but does not support VS projects/solutions
generation. I only mention it if you're curious.

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