Plea to distribute debugging lib
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library.
http://www.boost.org/libs/python/doc/building.html#variants
explains. We wanted to make it reasonably convenient for Windows developers (and our distributed testers) to work with a debug build of the Boost.Python library and of their own code. Having to download the Python source and build the debug DLL was deemed unacceptable.
Well, those hacks have run out of road. VC++8 now detects that some of its headers have been #included with _DEBUG and some without, and it will refuse to build anything when it does. We have several new hacks to work around that detection, and I think we _might_ be able to get away with them for one more release. But it's really time to do it right. MS is recommending that we (Boost) start distributing a debug build of the Python DLL with Boost, but Boost really seems like the wrong place to host such a thing. Is there any way Python.org can make a debug build more accessible?
Thanks, Dave
David Abrahams dave@boost-consulting.com wrote:
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library.
[...]
Having to download the Python source and build the debug DLL was deemed unacceptable.
I'm curious: why was this "deemed unacceptable"? Python's license is about as liberal as it gets, and the code is almost startlingly easy to compile -- easier than any other similarly-sized codebase I've had to work with.
Charles
I vaguely recall that there were problems with distributing the debug version of the MS runtime.
Anyway, why can't you do this yourself for all Boost users? It's all volunteer time, you know...
--Guido
On 11/4/05, Charles Cazabon python@discworld.dyndns.org wrote:
David Abrahams dave@boost-consulting.com wrote:
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library.
[...]
Having to download the Python source and build the debug DLL was deemed unacceptable.
I'm curious: why was this "deemed unacceptable"? Python's license is about as liberal as it gets, and the code is almost startlingly easy to compile -- easier than any other similarly-sized codebase I've had to work with.
Charles
Charles Cazabon python@discworld.dyndns.org GPL'ed software available at: http://pyropus.ca/software/
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum guido@python.org writes:
I vaguely recall that there were problems with distributing the debug version of the MS runtime.
Right: the debug runtime dlls are not disributable.
Anyway, why can't you do this yourself for all Boost users? It's all volunteer time, you know...
Doesn't any boost user need a C compiler anyway, so it should not really be a problem to compile Python?
Anyway, AFAIK, the activestate distribution contains Python debug dlls.
Thomas
[Thomas Heller wrote]
Anyway, AFAIK, the activestate distribution contains Python debug dlls.
[Er, a month late, but I was in flitting around Australia at the time. :)]
Yes, as a separate download.
ftp://ftp.activestate.com/ActivePython/etc/ ActivePython-<version>-win32-ix86-debug.zip
And those should be binary compatible with the equivalent python.org installs as well. Note that the simple "install.py" script in those packages bails if the Python installation isn't ActivePython, but I could easily remove that if you think that would be useful for your users.
Trent
Trent Mick trentm@ActiveState.com writes:
[Thomas Heller wrote]
Anyway, AFAIK, the activestate distribution contains Python debug dlls.
[Er, a month late, but I was in flitting around Australia at the time. :)]
Yes, as a separate download.
ftp://ftp.activestate.com/ActivePython/etc/ ActivePython-<version>-win32-ix86-debug.zipAnd those should be binary compatible with the equivalent python.org installs as well. Note that the simple "install.py" script in those packages bails if the Python installation isn't ActivePython, but I could easily remove that if you think that would be useful for your users.
Yes, please!
Would Python.org be willing to post links to the Activestate package? That would help, too.
Trent Mick <trentm <at> ActiveState.com> writes:
[Thomas Heller wrote]
Anyway, AFAIK, the activestate distribution contains Python debug dlls.
[Er, a month late, but I was in flitting around Australia at the time. :)]
Yes, as a separate download.
ftp://ftp.activestate.com/ActivePython/etc/ ActivePython-<version>-win32-ix86-debug.zipAnd those should be binary compatible with the equivalent python.org installs as well. Note that the simple "install.py" script in those packages bails if the Python installation isn't ActivePython, but I could easily remove that if you think that would be useful for your users.
The only problem here is that there appears to be a lag in the release of ActivePython after Python itself is released.
Is there any chance of putting up just the debugging libraries a little earlier?
Thanks again, Dave
Dave Abrahams schrieb:
The only problem here is that there appears to be a lag in the release of ActivePython after Python itself is released.
Is there any chance of putting up just the debugging libraries a little earlier?
I may be out of context here: what is the precise problem in producing them yourself? Why do you need somebody else to do it for you?
Regards, Martin
"Martin v. Löwis" martin@v.loewis.de writes:
Dave Abrahams schrieb:
The only problem here is that there appears to be a lag in the release of ActivePython after Python itself is released.
Is there any chance of putting up just the debugging libraries a little earlier?
I may be out of context here: what is the precise problem in producing them yourself? Why do you need somebody else to do it for you?
At the moment I have too weak a server to provide those files, but that will change very soon. All that said, the Python and ActiveState teams need to be aware of each and every Python release and go through a standard release procedure anyway, whereas -- except for this problem -- I would not. I'm willing to try to add it if that's what works, and of course it's easy for me to say, but I think it adds a lot more overhead for me than it would for the other two groups.
David Abrahams schrieb:
At the moment I have too weak a server to provide those files, but that will change very soon. All that said, the Python and ActiveState teams need to be aware of each and every Python release and go through a standard release procedure anyway, whereas -- except for this problem -- I would not. I'm willing to try to add it if that's what works, and of course it's easy for me to say, but I think it adds a lot more overhead for me than it would for the other two groups.
It's a significant amount of work, either way. It will be larger for you when you do it the first time; after that, it will be the same amount of work for you that it would be for me. It will be easier for you than for me as you won't be acting under time pressure (whereas additional actions from me will delay the entire Python release, which, due to timezones, already significantly suffers from the need to create Windows binaries).
I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result.
Regards, Martin
"Martin v. Löwis" martin@v.loewis.de writes:
I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result.
I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries.
David Abrahams schrieb:
I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result.
I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries.
And there is not one of them who would be willing and able to build a debug release, and distribute that????
Regards, Martin
"Martin v. Löwis" martin@v.loewis.de writes:
David Abrahams schrieb:
I'm not sure whether you are requesting these for yourself or for somebody else. If for somebody else, that somebody else should seriously consider building Python himself, and publishing the result.
I'm requesting it for the many Boost.Python (heck, all Python 'C' API) users who find it a usability hurdle when their first visual studio projects fail to work properly in the default mode (debug) just because they don't have the right Python libraries.
And there is not one of them who would be willing and able to build a debug release, and distribute that????
I don't know.
[David Abrahams]
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library. ... MS is recommending that we (Boost) start distributing a debug build of the Python DLL with Boost, but Boost really seems like the wrong place to host such a thing. Is there any way Python.org can make a debug build more accessible?
Possibly. I don't do this anymore (this == build the Python Windows installers), but I used to. For some time I also made available a zip file containing various debug-build bits, captured at the time the official installer was built. We didn't (and I'm sure we still don't) want to include them in the main installer, because they bloat its size for something most users truly do not want.
I got sick of building the debug zip file, and stopped doing that too. No two users wanted the same set of stuff in it, so it grew to contain the union of everything everyone wanted, and then people complained that it was "too big". This is one of the few times in your Uncle Timmy's life that he said "so screw it -- do it yourself, you whiny baby whiners with your incessant baby whining you " ;-)
Based on that sure-to-be universal reaction from anyone who signs up for this, I'd say the best thing you could do to help it along is to define precisely (a) what an acceptable distribution format is; and, (b) what exactly it should contain. That, and being nice to Martin, would go a long way.
Tim Peters tim.peters@gmail.com writes:
[David Abrahams]
For years, Boost.Python has been doing some hacks to work around the fact that a Windows Python distro doesn't include the debug build of the library. ... MS is recommending that we (Boost) start distributing a debug build of the Python DLL with Boost, but Boost really seems like the wrong place to host such a thing. Is there any way Python.org can make a debug build more accessible?
Possibly. I don't do this anymore (this == build the Python Windows installers), but I used to. For some time I also made available a zip file containing various debug-build bits, captured at the time the official installer was built. We didn't (and I'm sure we still don't) want to include them in the main installer, because they bloat its size for something most users truly do not want.
I got sick of building the debug zip file, and stopped doing that too. No two users wanted the same set of stuff in it, so it grew to contain the union of everything everyone wanted, and then people complained that it was "too big". This is one of the few times in your Uncle Timmy's life that he said "so screw it -- do it yourself, you whiny baby whiners with your incessant baby whining you " ;-)
Based on that sure-to-be universal reaction from anyone who signs up for this, I'd say the best thing you could do to help it along is to define precisely (a) what an acceptable distribution format is; and, (b) what exactly it should contain.
Who knows what the whiny babies will accept? That said, I think people would be happy with a .zip file containing whatever is built by selecting the debug build in the VS project and asking it to build everything. (**)
That, and being nice to Martin,
I'm always as nice as Davidly possible to Martin!
would go a long way.
My fingers and toes are crossed.
Thanks!
(**) If you could build the ability to download the debugging binaries into the regular installer, that would be the shiznit, but I don't dare ask for it. ;-)
David Abrahams wrote:
Who knows what the whiny babies will accept? That said, I think people would be happy with a .zip file containing whatever is built by selecting the debug build in the VS project and asking it to build everything. (**)
I would go a step further than Tim: Send me (*) a patch to msi.py (which is used to build the distribution) that picks up the files and packages them in the desired way, and I will include the files it outputs in the official distribution. This is how the libpython24.a got in (and this is also the way in which it will get out again).
In the patch, preferably state whom to contact for the specific feature, as I won't be able to answer questions about it.
I don't have a personal need for the feature (I do have debug builds myself, and it takes only 10 minutes or so to create them), so I won't even have a way to test whether the feature works correctly.
Regards, Martin
(*) that is, sf.net/projects/python
"Martin v. Löwis" martin@v.loewis.de writes:
David Abrahams wrote:
Who knows what the whiny babies will accept? That said, I think people would be happy with a .zip file containing whatever is built by selecting the debug build in the VS project and asking it to build everything. (**)
I would go a step further than Tim: Send me (*) a patch to msi.py (which is used to build the distribution) that picks up the files and packages them in the desired way, and I will include the files it outputs in the official distribution. This is how the libpython24.a got in (and this is also the way in which it will get out again).
Not to look a gift horse in the mouth, but won't that cause the problem that Tim was worried about, i.e. a bloated Python installer?
In the patch, preferably state whom to contact for the specific feature, as I won't be able to answer questions about it.
I don't have a personal need for the feature (I do have debug builds myself, and it takes only 10 minutes or so to create them),
I know, me too. It's easy enough once you get started building Python. I just think it's too big a hump for many people.
so I won't even have a way to test whether the feature works correctly.
Regards, Martin
(*) that is, sf.net/projects/python
I s'pose that means, "put it in the patches tracker."
grateful-ly y'rs,
David Abrahams wrote:
I would go a step further than Tim: Send me (*) a patch to msi.py (which is used to build the distribution) that picks up the files and packages them in the desired way, and I will include the files it outputs in the official distribution. This is how the libpython24.a got in (and this is also the way in which it will get out again).
Not to look a gift horse in the mouth, but won't that cause the problem that Tim was worried about, i.e. a bloated Python installer?
Not if done properly: it would, of course, *not* add the desired files in to the msi file, but create a separate file. It is pure Python code, and called msi.py because that's it main function. It does several other things, though (such as creating a .cab file and a .a file); it could well create another zip file.
As to how it would work: preferably by invoking the Python zip library, but invoking external programs to package up everything might be acceptable as well (assuming I'm told what these tools are, and assuming it falls back to doing nothing if the tools are not available).
The separate file would have a name similar to the MSI file, so that the debug file has the same version number as the MSI file.
I s'pose that means, "put it in the patches tracker."
Exactly.
Regards, Martin
participants (8)
-
"Martin v. Löwis" -
Charles Cazabon -
Dave Abrahams -
David Abrahams
-
Guido van Rossum -
Thomas Heller -
Tim Peters -
Trent Mick