Friends,
I would like to exchange my experience on the VS debugging part, if I may.
If you load one of the "fake" VC projects from the GDAL source
distribution, makegdal71.vcproj or makegdal80.vcproj, it is pretty easy
to write in the Project Property Pages/Debugging what are your settings
for test anything basically. Ex.:
"""
Command: D:/gdal/apps/gdal_translate.exe
Command Arguments: -of gtiff input.vrt ouput.tif
Working Directory: D:/Data/Test
Environment: CPL_DEBUG=ON
"""
One note about environment variables, VS2003 doesn't have one entry for
"Environment" on the Project Property Pages, VS2005 does. But you can
always set them directly on windows. Just remember to close and open
VS2003 again so that it will catch the changes.
To run in debugging mode is pretty simple. You don't necessarily need to
create a complicate VS Solution and add several projects to it. Just add
the other project source folder to your source tree on "Solution/Explorer"
Just click on the left side of your source code line to make that little
red dot to show up and click on "Debug/Start".
I have used that to launch other application that would ultimately load
GDAL dll during the execution like:
Python:
"""
Command: "C:\Program
Files\Python24\Lib\site-packages\pythonwin\Pythonwin.exe"
"""
ArcMAP:
"""
Command: "C:\Program Files\ESRI\bin\ArcMap.exe"
"""
But another option is to attach to one existing/running process by using
the "Debug/Process" options.
I used to start PythonWin first and then attach to its process and make
calls to the specific function to test specific part of my code. It is
great.
If you are developing a driver that is not on the trunk yet you can run
the "fake" VS project generator that I wrote:
D:\GDAL > makegdal_gen.bat
Usage: makegdal_gen "MS Visual C++ version" > makegdalNN.vcproj
Examples:
makegdal_gen 7.10 > makegdal71.vcproj
makegdal_gen 8.00 > makegdal80.vcproj
That will update the source file tree.
Of course you can do that with XEmacs or GDB but VS is just more
comfortable and maybe improve your productivity to solve problems.
By the way, does anybody interested in developing a KDeveloper project
for GDAL? I can do that if there are demand for it. :)
Best regards,
Ivan
Mateusz Loskot wrote:
Cherif Oueslati wrote:
Hello every body,
I found a problem to run the GDAL 1.5.1 in a MS Visual Studio 2003
Environment, to test the implementation of a driver that i developed.
The error appears when i would like to run the project and indicates
that it
is impossible to begin the debug because it's impossible to start the
"gdal15.dll".
Cherif,
This is correct, you can no *run* a DLL (if you mean this as "start the
gdal15.dll") in any version of Visual Studio.
You need to add your own test program (.exe project) and attach its
project to the solution, configure dependencies and set your test
project as startup project.
If you don't know how to do it, refer MSDN and VS documentation:
http://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx
Someone suggest to me to well define the "environment variables".
Can you tell me how could i run gdal 1.5.1 or how to set the "environment
variables" inside the visual studio it self.
All this is well explained in the VS documentation:
http://msdn.microsoft.com/en-us/library/aa909648.aspx
But please notice, you do need to set environment variables to be able
to fully debug and test GDAL dll, but environment variables does not the
first problem. You still need to create a project for test program (.exe
application).
Another option but IMHO more difficult if you are not experienced with
VS and debugging, as Tamas suggested, is to attach debugging session to
a process started as .exe program, for example gdalinfo or ogrinfo.
In case you don't know how to configure and use Visual Studio debugger,
I recommend to read MSDN:
http://msdn.microsoft.com/en-us/library/d0b8xh0y.aspx
Best regards,
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
