Windows Debug build improvement
Hi, I tried to submit a improvement for the Windows build but the tracker is not accessible without a login. On Windows if someone does a Debug build of an extension the flag _DEBUG is set and so the Python Interpreter sets Py_DEBUG and for all extension modules "_d" is appended to load the debug version of a module. This is not really practical because then all modules and the Python Interpreter must be build in Debug mode. For some modules this is even not possible for Windows. :-( To do a debug build for a Cython generated extension with a normal Python Interpreter (none Debug) I have to patch the pyconfig.h file and undef _DEBUG or I must patch the generated c file from Cython to undef _DEBUG before pyconfig.h or Python.h is included. (and enable it afterwards) Is it possible to add a flag to Cython to generate code that does this ? Something like described in Boost.Python: http://hepunx.rl.ac.uk/BFROOT/dist/releases/26.0.0/boost/libs/python/doc/bui... It is enough to have a new Preprocessor Flag, if set, then surround the Python.h inclusion with a disabled _DEBUG. My workarround is to disable it before pyconfig.h (Python.h) include: #ifdef _DEBUG #undef _DEBUG #define _RESTORE #endif and enable it afterwards #ifdef _RESTORE #define _DEBUG #undef _RESTORE #endif Regards, Wolfgang
On Thu, 18 Jul 2013 19:24:21 +0600, Wolfgang <tds333@gmail.com> wrote:
Hi,
I tried to submit a improvement for the Windows build but the tracker is not accessible without a login.
On Windows if someone does a Debug build of an extension the flag _DEBUG is set and so the Python Interpreter sets Py_DEBUG and for all extension modules "_d" is appended to load the debug version of a module. This is not really practical because then all modules and the Python Interpreter must be build in Debug mode. For some modules this is even not possible for Windows. :-(
To debug my extensions on Windows (in Visual Studio), I just add the appropriate compiler flags: extension = Extension( ... extra_compile_args=['/Zi', '/Od'], # generate PDB, disable optimization extra_link_args=['/DEBUG']) # preserve debug info Add to that symbol files for the Python release you are using ("program database" links on this page http://www.python.org/getit/releases/2.7.5/) and you will have a comfortable debugging environment. Best regards, Nikita Nemkin
On Thu, Jul 18, 2013 at 6:24 AM, Wolfgang <tds333@gmail.com> wrote:
Hi,
I tried to submit a improvement for the Windows build but the tracker is not accessible without a login.
This is to prevent spam.
On Windows if someone does a Debug build of an extension the flag _DEBUG is set and so the Python Interpreter sets Py_DEBUG and for all extension modules "_d" is appended to load the debug version of a module. This is not really practical because then all modules and the Python Interpreter must be build in Debug mode. For some modules this is even not possible for Windows. :-(
To do a debug build for a Cython generated extension with a normal Python Interpreter (none Debug) I have to patch the pyconfig.h file and undef _DEBUG or I must patch the generated c file from Cython to undef _DEBUG before pyconfig.h or Python.h is included. (and enable it afterwards)
Is it possible to add a flag to Cython to generate code that does this ?
Something like described in Boost.Python: http://hepunx.rl.ac.uk/BFROOT/dist/releases/26.0.0/boost/libs/python/doc/bui...
It is enough to have a new Preprocessor Flag, if set, then surround the Python.h inclusion with a disabled _DEBUG.
My workarround is to disable it before pyconfig.h (Python.h) include:
#ifdef _DEBUG #undef _DEBUG #define _RESTORE #endif
and enable it afterwards
#ifdef _RESTORE #define _DEBUG #undef _RESTORE #endif
Seems like a fairly global change. At the very least it should be guarded with an #if [windows/msvc/?], and _RESTORE probably named __PYX_RESTORE_DEBUG or something less likely to clash. But it'd be really helpful for someone who uses and knows windows well to comment on the possible implications of this, as I don't even have a way to try it out.
On 25.07.2013 18:01, Robert Bradshaw wrote:
On Thu, Jul 18, 2013 at 6:24 AM, Wolfgang <tds333@gmail.com> wrote:
Hi,
I tried to submit a improvement for the Windows build but the tracker is not accessible without a login. This is to prevent spam.
On Windows if someone does a Debug build of an extension the flag _DEBUG is set and so the Python Interpreter sets Py_DEBUG and for all extension modules "_d" is appended to load the debug version of a module. This is not really practical because then all modules and the Python Interpreter must be build in Debug mode. For some modules this is even not possible for Windows. :-(
To do a debug build for a Cython generated extension with a normal Python Interpreter (none Debug) I have to patch the pyconfig.h file and undef _DEBUG or I must patch the generated c file from Cython to undef _DEBUG before pyconfig.h or Python.h is included. (and enable it afterwards)
Is it possible to add a flag to Cython to generate code that does this ?
Something like described in Boost.Python: http://hepunx.rl.ac.uk/BFROOT/dist/releases/26.0.0/boost/libs/python/doc/bui...
It is enough to have a new Preprocessor Flag, if set, then surround the Python.h inclusion with a disabled _DEBUG.
My workarround is to disable it before pyconfig.h (Python.h) include:
#ifdef _DEBUG #undef _DEBUG #define _RESTORE #endif
and enable it afterwards
#ifdef _RESTORE #define _DEBUG #undef _RESTORE #endif Seems like a fairly global change. At the very least it should be guarded with an #if [windows/msvc/?], and _RESTORE probably named __PYX_RESTORE_DEBUG or something less likely to clash. But it'd be really helpful for someone who uses and knows windows well to comment on the possible implications of this, as I don't even have a way to try it out.
Yes it should be guarded with special naming and only enabled if a new special option is set. If this new flag is not set everything is as now. A check for Windows is not needed, but don't bother. Something like: #ifdef __PYX_WIN_DEBUG # ifdef _DEBUG # undef _DEBUG # define __PYX_DEBUG_RESTORE # endif #endif ... Or test at code generation time for the flag __PYX_WIN_DEBUG and only then generate this surrounding code. Regards, Wolfgang
Who sets _DEBUG? Wouldn't manually undeffing _DEBUG be just as easy as manually setting __PYX_WIN_DEBUG? Disclaimer: I've never developed Python on Windows, but it seems that Nikita's solution is simpler. On Thu, Jul 25, 2013 at 12:11 PM, WL <tds333@gmail.com> wrote:
On 25.07.2013 18:01, Robert Bradshaw wrote:
On Thu, Jul 18, 2013 at 6:24 AM, Wolfgang <tds333@gmail.com> wrote:
Hi,
I tried to submit a improvement for the Windows build but the tracker is not accessible without a login.
This is to prevent spam.
On Windows if someone does a Debug build of an extension the flag _DEBUG is set and so the Python Interpreter sets Py_DEBUG and for all extension modules "_d" is appended to load the debug version of a module. This is not really practical because then all modules and the Python Interpreter must be build in Debug mode. For some modules this is even not possible for Windows. :-(
To do a debug build for a Cython generated extension with a normal Python Interpreter (none Debug) I have to patch the pyconfig.h file and undef _DEBUG or I must patch the generated c file from Cython to undef _DEBUG before pyconfig.h or Python.h is included. (and enable it afterwards)
Is it possible to add a flag to Cython to generate code that does this ?
Something like described in Boost.Python:
http://hepunx.rl.ac.uk/BFROOT/dist/releases/26.0.0/boost/libs/python/doc/bui...
It is enough to have a new Preprocessor Flag, if set, then surround the Python.h inclusion with a disabled _DEBUG.
My workarround is to disable it before pyconfig.h (Python.h) include:
#ifdef _DEBUG #undef _DEBUG #define _RESTORE #endif
and enable it afterwards
#ifdef _RESTORE #define _DEBUG #undef _RESTORE #endif
Seems like a fairly global change. At the very least it should be guarded with an #if [windows/msvc/?], and _RESTORE probably named __PYX_RESTORE_DEBUG or something less likely to clash. But it'd be really helpful for someone who uses and knows windows well to comment on the possible implications of this, as I don't even have a way to try it out.
Yes it should be guarded with special naming and only enabled if a new special option is set. If this new flag is not set everything is as now. A check for Windows is not needed, but don't bother.
Something like:
#ifdef __PYX_WIN_DEBUG # ifdef _DEBUG # undef _DEBUG # define __PYX_DEBUG_RESTORE # endif #endif
...
Or test at code generation time for the flag __PYX_WIN_DEBUG and only then generate this surrounding code.
Regards,
Wolfgang _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
participants (4)
-
Nikita Nemkin -
Robert Bradshaw -
WL -
Wolfgang