> On 9 Jan 2018, at 20:35, Ivan Pozdeev wrote:
>
> On 09.01.2018 23:31, Barry Scott wrote:
>> I not a user of distutils or setuptools but some googling seems to say that
>> the build command has a --debug to do what you want. If that does not
>> work it would seem like you could ask the setupto
I not a user of distutils or setuptools but some googling seems to say that
the build command has a --debug to do what you want. If that does not
work it would seem like you could ask the setuptools maintainers how to
do the reason thing of a debug build.
Barry
> On 9 Jan 2018, at 18:46, Ivan Po
On 09.01.2018 23:31, Barry Scott wrote:
I not a user of distutils or setuptools but some googling seems to say
that
the build command has a --debug to do what you want. If that does not
work it would seem like you could ask the setuptools maintainers how to
do the reason thing of a debug build.
On 09.01.2018 21:35, Ivan Pozdeev via Python-ideas wrote:
On 08.01.2018 0:11, Steve Dower wrote:
It’s not a good idea. You end up with two different C runtimes in
memory that cannot communicate, and many things will not work properly.
If you compile your debug build extension with the non-d
On 08.01.2018 0:11, Steve Dower wrote:
It’s not a good idea. You end up with two different C runtimes in
memory that cannot communicate, and many things will not work properly.
If you compile your debug build extension with the non-debug CRT (/MD
rather than /MDd) you will lose asserts, but
It’s not a good idea. You end up with two different C runtimes in memory that
cannot communicate, and many things will not work properly.
If you compile your debug build extension with the non-debug CRT (/MD rather
than /MDd) you will lose asserts, but otherwise it will work fine and the
quoted
