Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

2018-01-09 Thread Barry Scott 


> 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 setuptools maintainers how to
>> do the reason thing of a debug build.
>> 
> I just wrote, in 
> https://mail.python.org/pipermail/python-ideas/2018-January/048579.html , 
> that --debug is not sufficient, and that the problematic logic is in 
> distutils, not setuptools.

Sorry, I mis-read that. I thought it was not a known option.
It is certainly hard to find docs for.

This does sound like something the setup tools people can answer for you.
I think they hang out on the python distutils-sig mailing list.

Barry

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

2018-01-09 Thread Barry Scott 
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 Pozdeev via Python-ideas 
> <python-ideas@python.org> wrote:
> 
> 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-debug CRT (/MD 
>>> rather than /MDd) you will lose asserts, but otherwise it will work fine 
>>> and the quoted code picks the release lib.
>> Distutils' designers seem to have thought differently.
>> Whether the extension is linked against pythonxx_d.lib is governed by the 
>> --debug switch to the `build' command rather than the type of the running 
>> Python. Compiler optimization flags and /MD(d) are inserted according to it, 
>> too.
>> 
>> As a consequence,
>> * I cannot install an extension into debug Python at all 'cuz `bdist_*' and 
>> `install' commands don't support --debug and invoke `debug' internally 
>> without it.
> I meant "invoke `build' internally without it." , sorry.
> 
> This kafkaesque "you cannot do this because you cannot do this" is taking its 
> toll on me...
>> * Neither can I compile an extension for release Python without 
>> optimizations.
>> 
>> I'm at a loss here. Either I'm missing something, or with the current build 
>> system, it's impossible to debug extensions!
>>>  
>>> Or if you like, when you install Python 3.5 or later there are advanced 
>>> options to install debug symbols and binaries. You can use a proper debug 
>>> build against the debug binaries (python_d.exe).
>>>  
>>> Cheers,
>>> Steve
>>>  
>>> Top-posted from my Windows phone
>>>  
>>> From: Ivan Pozdeev via Python-ideas <mailto:python-ideas@python.org>
>>> Sent: Saturday, December 30, 2017 13:01
>>> To: python-ideas@python.org <mailto:python-ideas@python.org>
>>> Subject: [Python-ideas] Allow to compile debug extension against 
>>> releasePython in Windows
>>>  
>>> The Windows version of pyconfig.h has the following construct:
>>>  
>>> if defined(_DEBUG)
>>>pragma comment(lib,"python37_d.lib")
>>> elif defined(Py_LIMITED_API)
>>>pragma comment(lib,"python3.lib")
>>> else
>>>pragma comment(lib,"python37.lib")
>>> endif /* _DEBUG */
>>>  
>>> which fails the compilation of a debug version of an extension. Making
>>> debugging it... difficult.
>>>  
>>> Perhaps we could define some other constant?
>>>  
>>> I'm not sure whether such compilation is a good idea in general, so
>>> asking here at first.
>>>  
>>> --
>>> Regards,
>>> Ivan
>>>  
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org <mailto:Python-ideas@python.org>
>>> https://mail.python.org/mailman/listinfo/python-ideas 
>>> <https://mail.python.org/mailman/listinfo/python-ideas>
>>> Code of Conduct: http://python.org/psf/codeofconduct/ 
>>> <http://python.org/psf/codeofconduct/>
>>>  
>> 
>> -- 
>> Regards,
>> Ivan
>> 
>> 
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org <mailto:Python-ideas@python.org>
>> https://mail.python.org/mailman/listinfo/python-ideas 
>> <https://mail.python.org/mailman/listinfo/python-ideas>
>> Code of Conduct: http://python.org/psf/codeofconduct/ 
>> <http://python.org/psf/codeofconduct/>
> 
> -- 
> Regards,
> Ivan
> ___
> Python-ideas mailing list
> Python-ideas@python.org <mailto:Python-ideas@python.org>
> https://mail.python.org/mailman/listinfo/python-ideas 
> <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/ 
> <http://python.org/psf/codeofconduct/>

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

2018-01-09 Thread Ivan Pozdeev via Python-ideas 

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.

I just wrote, in 
https://mail.python.org/pipermail/python-ideas/2018-January/048579.html 
, that --debug is not sufficient, and that the problematic logic is in 
distutils, not setuptools.


--
Regards,
Ivan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

2018-01-09 Thread Ivan Pozdeev via Python-ideas 

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-debug CRT (/MD 
rather than /MDd) you will lose asserts, but otherwise it will work 
fine and the quoted code picks the release lib.



Distutils' designers seem to have thought differently.
Whether the extension is linked against pythonxx_d.lib is governed by 
the --debug switch to the `build' command rather than the type of the 
running Python. Compiler optimization flags and /MD(d) are inserted 
according to it, too.


As a consequence,
* I cannot install an extension into debug Python at all 'cuz 
`bdist_*' and `install' commands don't support --debug and invoke 
`debug' internally without it.

I meant "invoke `build' internally without it." , sorry.

This kafkaesque "you cannot do this because you cannot do this" is 
taking its toll on me...
* Neither can I compile an extension for release Python without 
optimizations.


I'm at a loss here. Either I'm missing something, or with the current 
build system, it's impossible to debug extensions!


Or if you like, when you install Python 3.5 or later there are 
advanced options to install debug symbols and binaries. You can use a 
proper debug build against the debug binaries (python_d.exe).


Cheers,

Steve

Top-posted from my Windows phone

*From: *Ivan Pozdeev via Python-ideas <mailto:python-ideas@python.org>
*Sent: *Saturday, December 30, 2017 13:01
*To: *python-ideas@python.org <mailto:python-ideas@python.org>
*Subject: *[Python-ideas] Allow to compile debug extension against 
releasePython in Windows


The Windows version of pyconfig.h has the following construct:

    if defined(_DEBUG)

   pragma comment(lib,"python37_d.lib")

    elif defined(Py_LIMITED_API)

   pragma comment(lib,"python3.lib")

    else

   pragma comment(lib,"python37.lib")

    endif /* _DEBUG */

which fails the compilation of a debug version of an extension. Making

debugging it... difficult.

Perhaps we could define some other constant?

I'm not sure whether such compilation is a good idea in general, so

asking here at first.

--

Regards,

Ivan

___

Python-ideas mailing list

Python-ideas@python.org

https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/



--
Regards,
Ivan


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow to compile debug extension against releasePython in Windows

2018-01-09 Thread Ivan Pozdeev via Python-ideas 

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 otherwise it will work 
fine and the quoted code picks the release lib.



Distutils' designers seem to have thought differently.
Whether the extension is linked against pythonxx_d.lib is governed by 
the --debug switch to the `build' command rather than the type of the 
running Python. Compiler optimization flags are inserted according to 
it, too.


As a consequence,
* I cannot install an extension into debug Python at all 'cuz `bdist_*' 
and `install' commands don't support --debug and invoke `debug' 
internally without it.
* Neither can I compile an extension for release Python without 
optimizations.


I'm at a loss here. Either I'm missing something, or with the current 
build system, it's impossible to debug extensions!


Or if you like, when you install Python 3.5 or later there are 
advanced options to install debug symbols and binaries. You can use a 
proper debug build against the debug binaries (python_d.exe).


Cheers,

Steve

Top-posted from my Windows phone

*From: *Ivan Pozdeev via Python-ideas <mailto:python-ideas@python.org>
*Sent: *Saturday, December 30, 2017 13:01
*To: *python-ideas@python.org <mailto:python-ideas@python.org>
*Subject: *[Python-ideas] Allow to compile debug extension against 
releasePython in Windows


The Windows version of pyconfig.h has the following construct:

    if defined(_DEBUG)

   pragma comment(lib,"python37_d.lib")

    elif defined(Py_LIMITED_API)

   pragma comment(lib,"python3.lib")

    else

   pragma comment(lib,"python37.lib")

    endif /* _DEBUG */

which fails the compilation of a debug version of an extension. Making

debugging it... difficult.

Perhaps we could define some other constant?

I'm not sure whether such compilation is a good idea in general, so

asking here at first.

--

Regards,

Ivan

___

Python-ideas mailing list

Python-ideas@python.org

https://mail.python.org/mailman/listinfo/python-ideas

Code of Conduct: http://python.org/psf/codeofconduct/



--
Regards,
Ivan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/