[Gdal-dev] Visual Studio Project Files

[Simon Perkins]

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.


I don't think that nmake is going to go away - too many people depend on
it. But my feeling is that it's probably not Microsoft's priority. I see
the IDE becoming more central to the build process and having to jump
through more and more hoops to make nmake work. I'll admit that this is
more of a gut feeling than anything else, but I do know that when I
recently switched a cross-platform project of mine from SCons to visual
studio project files, a lot of things became easier on windows! We
already have to maintain a set of build scripts for Visual Studio (the
makefile.vc files) that are independent from the UNIX makefiles, so my
question was whether it would be worth migrating to, or adding, an IDE
based set of script (project files).



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

OK, it's not impossible...

They seem to have improved their docs on this since I last looked as
well...


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



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


Cheers,

Sy