Changes in r72585
[coming from a thread on python-win32: http://mail.python.org/pipermail/python-win32/2009-May/009130.html ] In short: changes to build_ext.py in r72585 caused the pywin32 packages to stop building correctly. The changes in question are those which call get_ext_filename with the short form of the ext.name (without the package prefix). The pywin32 setup.py expects the fully-qualified name in the get_ext_filename in its subclass. Now I don't know whether this is an incautious change to build_ext or a false -- altho' historically valid -- assumption on the part of the pywin32 developers. You can see their code here at line 1119: http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup I'm afraid I'm fairly ignorant of the design rationale behind distutils; I'm hoping someone here has a better idea :) Opinions? TJG
Hi Tim, thanks for the feedback, this has been fixed in r72758 http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758 Regards Tarek On Tue, May 19, 2009 at 4:00 PM, Tim Golden <mail@timgolden.me.uk> wrote:
[coming from a thread on python-win32: http://mail.python.org/pipermail/python-win32/2009-May/009130.html ]
In short: changes to build_ext.py in r72585 caused the pywin32 packages to stop building correctly. The changes in question are those which call get_ext_filename with the short form of the ext.name (without the package prefix). The pywin32 setup.py expects the fully-qualified name in the get_ext_filename in its subclass.
Now I don't know whether this is an incautious change to build_ext or a false -- altho' historically valid -- assumption on the part of the pywin32 developers. You can see their code here at line 1119:
http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup
I'm afraid I'm fairly ignorant of the design rationale behind distutils; I'm hoping someone here has a better idea :)
Opinions?
TJG _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
By the way, Do you happen to have a pywin32 buildbot that could run on the python trunk ? (where I can get emails when it's broken) That would be useful because I am doing a lot of work in the trunk. Tarek On Tue, May 19, 2009 at 4:54 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Hi Tim, thanks for the feedback,
this has been fixed in r72758
http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758
Regards Tarek
On Tue, May 19, 2009 at 4:00 PM, Tim Golden <mail@timgolden.me.uk> wrote:
[coming from a thread on python-win32: http://mail.python.org/pipermail/python-win32/2009-May/009130.html ]
In short: changes to build_ext.py in r72585 caused the pywin32 packages to stop building correctly. The changes in question are those which call get_ext_filename with the short form of the ext.name (without the package prefix). The pywin32 setup.py expects the fully-qualified name in the get_ext_filename in its subclass.
Now I don't know whether this is an incautious change to build_ext or a false -- altho' historically valid -- assumption on the part of the pywin32 developers. You can see their code here at line 1119:
http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup
I'm afraid I'm fairly ignorant of the design rationale behind distutils; I'm hoping someone here has a better idea :)
Opinions?
TJG _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
-- Tarek Ziadé | http://ziade.org
Tarek Ziadé wrote:
By the way,
Do you happen to have a pywin32 buildbot that could run on the python trunk ? (where I can get emails when it's broken)
I have what you might call a manual buildbot. (A buildman?) I have set up an environment where I can create installers for python trunk & pywin32 for the trunk and principal branches (release-maint26 / py3k). Once I've ironed out the issues with those, I hope to be able to do the same for other simple projects such as pyodbc which don't require large amounts of library configuration. Ultimately, I hope to be able to link into something like snakebite.org to produce overnight build MSIs of Windows projects. (Long-term plan, tho'!) TJG
That would be useful because I am doing a lot of work in the trunk.
Tarek
On Tue, May 19, 2009 at 4:54 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Hi Tim, thanks for the feedback,
this has been fixed in r72758
http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758
Regards Tarek
On Tue, May 19, 2009 at 4:00 PM, Tim Golden <mail@timgolden.me.uk> wrote:
[coming from a thread on python-win32: http://mail.python.org/pipermail/python-win32/2009-May/009130.html ]
In short: changes to build_ext.py in r72585 caused the pywin32 packages to stop building correctly. The changes in question are those which call get_ext_filename with the short form of the ext.name (without the package prefix). The pywin32 setup.py expects the fully-qualified name in the get_ext_filename in its subclass.
Now I don't know whether this is an incautious change to build_ext or a false -- altho' historically valid -- assumption on the part of the pywin32 developers. You can see their code here at line 1119:
http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/setup.py?revision=1.107&view=markup
I'm afraid I'm fairly ignorant of the design rationale behind distutils; I'm hoping someone here has a better idea :)
Opinions?
TJG _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
On Tuesday 19 May 2009 16:08:43 Tim Golden wrote:
Tarek Ziadé wrote:
By the way,
Do you happen to have a pywin32 buildbot that could run on the python trunk ? (where I can get emails when it's broken)
I have what you might call a manual buildbot. (A buildman?) I have set up an environment where I can create installers for python trunk & pywin32 for the trunk and principal branches (release-maint26 / py3k).
It looks like a continuous integration is in need. As you might remember from a previous thread, I am doing something for the python intepreter. It is based on the suse build server so it covers several rpm linux distro already (fedora, centos and suse). As part of it I wrote also few smoke tests to verify that things work well and they're integrated in the rpmbuild process. Regards, Antonio
On Tue, May 19, 2009 at 5:17 PM, A. Cavallo <a.cavallo@cavallinux.eu> wrote:
On Tuesday 19 May 2009 16:08:43 Tim Golden wrote:
Tarek Ziadé wrote:
By the way,
Do you happen to have a pywin32 buildbot that could run on the python trunk ? (where I can get emails when it's broken)
I have what you might call a manual buildbot. (A buildman?) I have set up an environment where I can create installers for python trunk & pywin32 for the trunk and principal branches (release-maint26 / py3k).
It looks like a continuous integration is in need. As you might remember from a previous thread, I am doing something for the python intepreter.
It is based on the suse build server so it covers several rpm linux distro already (fedora, centos and suse).
As part of it I wrote also few smoke tests to verify that things work well and they're integrated in the rpmbuild process.
Yes I remember that. Are you able to automate this when distutils trunk is changed ? If not, I'd love to help. If it's already the case, having mails sent here on failures would be a blast Tarek -- Tarek Ziadé | http://ziade.org
Tarek Ziadé wrote:
Hi Tim, thanks for the feedback,
this has been fixed in r72758
http://svn.python.org/view/python/trunk/Lib/distutils/command/build_ext.py?r1=72593&r2=72758
'fraid not :) It was running against r72758 which showed the bug up: I had to back-track through a few revisions to find what introduced it. The attached patch against r72780 "fixes" the problem (ie makes pywin32 build correctly) but since I've no real idea what the intention of the code is, I've likewise no idea of what I might be breaking by doing this :( TJG Index: Lib/distutils/command/build_ext.py =================================================================== --- Lib/distutils/command/build_ext.py (revision 72780) +++ Lib/distutils/command/build_ext.py (working copy) @@ -652,7 +652,8 @@ filename = self.get_ext_filename(ext_name) return os.path.join(package_dir, filename) else: - filename = self.get_ext_filename(ext_name) + fullname = self.get_ext_fullname(ext_name) + filename = self.get_ext_filename(fullname) return os.path.join(self.build_lib, filename) def get_ext_fullname(self, ext_name):
On Tue, May 19, 2009 at 5:01 PM, Tim Golden <mail@timgolden.me.uk> wrote:
Index: Lib/distutils/command/build_ext.py =================================================================== --- Lib/distutils/command/build_ext.py (revision 72780) +++ Lib/distutils/command/build_ext.py (working copy) @@ -652,7 +652,8 @@ filename = self.get_ext_filename(ext_name) return os.path.join(package_dir, filename) else: - filename = self.get_ext_filename(ext_name) + fullname = self.get_ext_fullname(ext_name) + filename = self.get_ext_filename(fullname) return os.path.join(self.build_lib, filename)
def get_ext_fullname(self, ext_name):
Ok I see what's wrong. I am writing a test + fix right away. build_ext and all the compiling code is still really undertested in Distutils. I've kinda opened a can of worms since I am working on the compilers part of the package. I'll let you know when it's fixed. ++ Tarek -- Tarek Ziadé | http://ziade.org
Tarek Ziadé wrote:
On Tue, May 19, 2009 at 5:01 PM, Tim Golden <mail@timgolden.me.uk> wrote:
Index: Lib/distutils/command/build_ext.py =================================================================== --- Lib/distutils/command/build_ext.py (revision 72780) +++ Lib/distutils/command/build_ext.py (working copy) @@ -652,7 +652,8 @@ filename = self.get_ext_filename(ext_name) return os.path.join(package_dir, filename) else: - filename = self.get_ext_filename(ext_name) + fullname = self.get_ext_fullname(ext_name) + filename = self.get_ext_filename(fullname) return os.path.join(self.build_lib, filename)
def get_ext_fullname(self, ext_name):
Ok I see what's wrong. I am writing a test + fix right away.
build_ext and all the compiling code is still really undertested in Distutils. I've kinda opened a can of worms since I am working on the compilers part of the package.
I'll let you know when it's fixed.
Thanks. Happy to run it through my "buildman" to check it covers that case. TJG
participants (3)
-
A. Cavallo -
Tarek Ziadé -
Tim Golden