Page MenuHome

msvc 2017: Add support for debugging python scripts from within visual studio 2017.5

Authored by Ray molenkamp (LazyDodo) on Feb 4 2018, 1:38 AM.



First of all it's probably easier to show what this does:

in case it's not obvious, what's happening.

@0:00 I change the debugger to the new mixed mode native/python debugger.
@0:15 I set a break point in the .obj importer/exporters register function.
@0:30 break point hit, full support for inspecting python variables!
@0:36 But what if we want to trace into that native C register_class function? well just step into it! seamlessly! Also check out the call-stack!


  • Visual Studio 2017 update 5 (15.5) with the Python native development tools option for the Python Development workload in the Visual Studio installer.
  • PDB files for our python (linked below), they need to be copied to the win64_vc14\lib\python\lib folder, next to the .dlls I'll add them to svn if this diff gets accepted.

  • WINDOWS_PYTHON_DEBUG (advanced option) will have to be set in cmake, to copy the pdb files to the right run-time location and create a little helper project blender_python_runtime_scripts that has all the scripts in it that blender uses at run-time.

The good:
-It's quite amazing and will save people developing on windows heaps of time.
-All of this is optional, if you don't want to use it, you don't have to and won't even notice it.
-Works in release mode (ie in a blender release build, you can still debug through any .py file you want)

The bad:
Startup performance isn't great, however using the mixed mode debugger is optional, if you just work in C , just switch is back to the 'local windows debugger' and things will be as they always were.

The nasty:
given the blenders run-time files get populated during the INSTALL phase and cmake refusing to make a project with files that do not exist yet, populating blender_python_runtime_scripts is kind of a 'difficult'*cough*a dirty hack*cough*, you have to build the 'INSTALL' project then re-run cmake to populate the project. Not great. not great at all. however the benefit of being able to debug .py/c seamlessly imho is worth it. If someone has a better idea i'm all ears. I left a little readme in the project just in case someone gets confused about this.

some background information about the new support in visual studio here:

Diff Detail

rB Blender

Event Timeline

Ray molenkamp (LazyDodo) edited the summary of this revision. (Show Details)Feb 4 2018, 1:54 AM

Since Visual Studio does not display files that do not exist (and Cmake does not allow it), I think a warning with the suggestion of the readme.txt is enough. So users would have no doubts as to why the python files did not appear.

actually we could sidestep this issue by not using the scripts from bin/debug/2.79/scripts, but pointing blender to the original scripts in the source tree like this P603 ,didn't update the diff, cause there's actual behavioral changes in appdir.c here that might affect end users. I'd like @Campbell Barton (campbellbarton)'s opinion on that change first.

this also changes the developer workflow from

1. Edit a a .py script in release/scripts.
2. build INSTALL
3. Run blender
4. Goto 1

(or lets be honest, the workflow is really like)

1. Edit a a .py script in release/scripts.
2. build INSTALL
3. Run blender
4. Edit a a .py script in release/scripts.
5. build INSTALL
6. Run blender
7. well this is annoying..
8. Edit a a .py script in bin/debug/2.79/scripts
9. Run blender
8. Edit a a .py script in bin/debug/2.79/scripts
9. Run blender
10. accidentally build INSTALL
11. Run blender
12 *DAMNIT!*


1. Edit a a .py script in release/scripts.
2. Run blender
3. goto 1

arc decided to make a new one instead of updating this one, i'm done fighting arc..

Any chance to get updated pdb for current python37 ?

pdb is in svn nowdays and should be updated for 3.7 already