Switching to VC.NET 2003
In my own sandbox, I have prepared project files for VC.NET. Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages. Regards, Martin
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages.
Will the resulting installer still install a working version of Python on old versions of Windows, like win95 and win98? I presume this will require that the MSI support is present on the target system; does this exist for Win95 etc? How about Windows NT 4.0? If not, what's the oldest Windows version still supported? --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Will the resulting installer still install a working version of Python on old versions of Windows, like win95 and win98?
I don't know; in principle, it should (or atleast, we should be able to make it work if desired).
I presume this will require that the MSI support is present on the target system; does this exist for Win95 etc? How about Windows NT 4.0?
Yes; there is a four-file bootstrap mechanism that we could distribute. It consists of 1. a tiny setup.exe 2. an installer for installer for W9x 3. an installer for installer for WNT 4. the actual MSI file. I believe the setup.exe driver needs to be parametrized as part of the build process to hard-code the name of the MSI file; I have no procedure yet to do this. I would propose to make parts 1..3 optional downloads; we can also (alternatively) point users to the redistributable download at http://www.microsoft.com/msdownload/platformsdk/instmsi.htm With that procedure, they would explicitly need to install installer, then reboot (I think), then install Python. On some installations, installer might be present already, but in a too-old version (I use the schema of Installer 2.0). In principle, the already-present installer should find out that it is too old, and suggest some sort of upgrade.
If not, what's the oldest Windows version still supported?
A different question is the version of shared libraries that the Python binaries depend on. On the one hand, this is msvcr71.dll, which is not present by default on any Windows release, so we need to ship that. Another issue is Winsock 2 (which, I believe, is in wsock32.dll). A quick research indicates that this was present in Win95 already. I don't know whether all of the entry points that we use was present already; confirmation appreciated. In principle, usage of IPv6 could be a problem. In another principle, the platform SDK arranges to transparently emulate the IPv6 API on systems where it is not natively available, by means of GetProcAddress. This all needs testing. Regards, Martin
Martin v. Loewis wrote:
On some installations, installer might be present already, but in a too-old version (I use the schema of Installer 2.0). In principle, the already-present installer should find out that it is too old, and suggest some sort of upgrade.
Following up to myself: If this turns out to be a frequent problem, we could probably go back to an older installer scheme - in particular, if we don't want to fight Windows File Protection (which is only transparently supported in most recent installer versions). In the sample installer, I put python24.dll into TARGETDIR, not into System32Folder. I'd like to keep it that way, as Microsoft discourages deployment into system32. Of course, if there is a good reason to install python24.dll into system32, changing the installer generator to do so would be only a small effort. Regards, Martin
[Martin v. Loewis]
...
In the sample installer, I put python24.dll into TARGETDIR, not into System32Folder. I'd like to keep it that way, as Microsoft discourages deployment into system32. Of course, if there is a good reason to install python24.dll into system32, changing the installer generator to do so would be only a small effort.
We need to hear from Mark Hammond about this, but he's on vacation now. The current installer's "non-admin install" option leaves system folders alone, and works fine for everything I routinely do on Windows. The point to stuffing the Python DLL into a system directory had (IIRC) something to do with a Windows Service embedding a Python component via COM, in which case "the virtual command line" that started the service has no idea where Python might live on the box. Or something like that -- or something not like that at all. That's why we need Mark <wink>.
Tim Peters wrote:
The point to stuffing the Python DLL into a system directory had (IIRC) something to do with a Windows Service embedding a Python component via COM, in which case "the virtual command line" that started the service has no idea where Python might live on the box.
Ah, ok. I'll figure out in the mean time how to incorporate msvcr71.dll into the package in the first place; putting it then into a "shared component" (along with pythonxy.dll) should be trivial. Regards, Martin
[Martin v. Loewis]
...
In the sample installer, I put python24.dll into TARGETDIR, not into System32Folder. I'd like to keep it that way, as Microsoft discourages deployment into system32. Of course, if there is a good reason to install python24.dll into system32, changing the installer generator to do so would be only a small effort.
We need to hear from Mark Hammond about this, but he's on vacation now. The current installer's "non-admin install" option leaves system folders alone, and works fine for everything I routinely do on Windows. The point to stuffing the Python DLL into a system directory had (IIRC) something to do with a Windows Service embedding a Python component via COM, in which case "the virtual command line" that started the service has no idea where Python might live on the box. Or something like that -- or something not like that at all. That's why we need Mark <wink>.
The underlying issue has to do with embedding Python. It is most visible with COM, but exists for any applicaiton that attempts to embed a 'stand-alone' Python installation. If they also ship Python with their app, the problem generally is trivial to work around by placing everything in the same directory, and indeed how py2exe works without putting anything in system32. Consider a Python implemented COM object. Some arbitrary process (eg, Outlook loading SpamBayes) finds the COM object is supported by loading pythoncom24.dll (as this DLL has the necessary COM entry points). Obviously, pythoncom24.dll references symbols in python24.dll. The problem is that the loading of pythoncom24.dll fails, due to failure to find python24.dll. COM itself has done the LoadLibrary() for pythoncom24, as part of the process outlook.exe. The Windows documentation for LoadLibrary() indicates the directory of the DLL being loaded is *not* searched for dependent DLLs. As it is not our code doing the LoadLibrary(), we can not move to LoadLibraryEx(). Thus, the only reasonable solution I see is for python24.dll to be on the global path. The easiest way to achieve that is to copy it to system32. Another real example: The win32all installer also embeds Python, via a WISE extension DLL. Again, it is WISE itself that loads its extension DLL, and this DLL has references to Python24.dll. I could find no way to make this work, short of insisting that people launch the installation .EXE from the main Python directory. (This installer is going to die very soon, but the underlying issue is not <wink>) Even a simple .EXE that tries to directly embed Python will have the same issue - the executable will need to live in the same directory as the Python DLL, or will fail to load. In most cases, people will just run it from that directory, but it doesn't seem a reasonable solution. XP is supposed to have some new features regarding this, but I have not looked into it at all. In summary, we need to ensure that an arbitrary DLL with symbol references to python24.dll can be loaded by an arbitrary process. Arbitrarily yrs, Mark.
Mark Hammond wrote:
XP is supposed to have some new features regarding this, but I have not looked into it at all.
JFYI, relevant link "Windows XP: Kernel Improvements" http://msdn.microsoft.com/msdnmag/issues/01/12/xpkernel/default.aspx (part "Application Compatibility-Side-by-side Assemblies") addresses new features of Win2k and XP regarding DLL. Mike
Mark Hammond wrote:
In summary, we need to ensure that an arbitrary DLL with symbol references to python24.dll can be loaded by an arbitrary process.
Ok. I have now fixed the installer to put pythonxy.dll (and msvcr71.dll) into System32, and enabled library reference counting for it. I should remember to record your explanation in the MSI generator. Regards, Martin
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages.
Are you using a Visual Studio "project" or a makefile based build? I believe you need a makefile based build if you want to let people develop with the free SDK from microsoft. I have some notes here that I posted a while ago: http://tinyurl.com/34ljh
logistix wrote:
Are you using a Visual Studio "project" or a makefile based build? I believe you need a makefile based build if you want to let people develop with the free SDK from microsoft.
I'm using project files, so users of the free compiler would have to write their makefiles themselves. It might be possible to write a generator that produces a makefile automatically from the VC.NET project files; contributions are welcome. Maintaining both project files and makefiles in parallel is not feasible; dropping the project files is also unacceptable. Regards, Martin
On Monday 29 December 2003 05:06 pm, Martin v. Loewis wrote: ...
It might be possible to write a generator that produces a makefile automatically from the VC.NET project files; contributions
At the time of Visual Studio 6, such a "generator" had been written by Microsoft, and was part of the VS6 package -- i.e., you could produce and save a makefile for the project you had loaded. Is this no more the case for the current release of Visual Studio...? Alex
Alex Martelli wrote:
At the time of Visual Studio 6, such a "generator" had been written by Microsoft, and was part of the VS6 package -- i.e., you could produce and save a makefile for the project you had loaded. Is this no more the case for the current release of Visual Studio...?
No. Microsoft has dropped that feature (perhaps they will restore it in VS.NET 2005 or something :-( However, it is now simpler to process project files; they are XML files with a fairly obvious vocabulary (*). A friend of mine once wrote a generator that produces GNU makefiles out of vcproj files; such generators tend to be quite application-specific, as they need to take custom build steps into account, and translate them properly. Most likely, the generator we would use would not be useful outside Python. I would like to see a single makefile generated, instead of one per project, as the VC6 generator would do; having so many makefiles is painful. That makefile should have an "all" target in addition to the targets for the individual projects. Regards, Martin (*) OTOH, the "solution" files (formerly workspaces) don't use XML syntax, and have changed between VS.NET 2002 and VS.NET 2003. They would need to be considered as well, as they contain the inter-project dependencies (including the list of all projects in the solution).
Martin v. Loewis wrote:
No. Microsoft has dropped that feature (perhaps they will restore it in VS.NET 2005 or something :-(
However, it is now simpler to process project files; they are XML files with a fairly obvious vocabulary (*). A friend of mine once wrote a generator that produces GNU makefiles out of vcproj files; such generators tend to be quite application-specific, as they need to take custom build steps into account, and translate them properly. Most likely, the generator we would use would not be useful outside Python.
I can suggest the fact that Scons can handle multiple builders (cygwin, mingw, VC6, VC7, VC7.1) easily and for VC it can generate the proper Project files? Can be a solution to support a single scons (makefile like) file and from that generate the proper project files? Users that wants to keep working with the IDE can do that! A free solution for a user that want to build python in a win32 environment without Visual Studio (whatever edition) could be: - Download python (from 1.5.2 above) and scons (as a make replacement) - Build python with the free Microsoft SDK compiler via scons. Scons has also an integrated autoconf-like environment, so it's possible to have a path to unify the classic configure/make *nix way with the win32 one. BTW, scons makefiles are just python files! Think only about the *update the python build number* problem that arose some times ago! It's trivial if handled by a builder script with-python-steroids! --- Paolo Invernizzi
Paolo Invernizzi wrote:
Can be a solution to support a single scons (makefile like) file and from that generate the proper project files?
That might be an option, but not the one I'm working on; it isn't even one that I'm particularly interested in. If I were maintaining the Windows port (which I'm not), I would dislike the solution because it would mean I have to learn scons...
Users that wants to keep working with the IDE can do that!
... and it would also mean that I *cannot* work with the IDE: I cannot make modifications to the projects in the IDE, because I would have to make the modifications in the scons files, not in the VC projects.
A free solution for a user that want to build python in a win32 environment without Visual Studio (whatever edition) could be:
- Download python (from 1.5.2 above) and scons (as a make replacement) - Build python with the free Microsoft SDK compiler via scons.
Such a free solution is already available, through cygwin/mingw. However, this is free software, so if you are interested, feel free to contribute. If you want your contribution be accepted, be prepared to answer "yes" to the question "Are you going to maintain the build process for the next three years"? If somebody volunteers to maintain such a build process, I would not object to having this process in parallel to the VC build process (to which I'm willing to contribute, for the next three years). Regards, Martin
Martin v. Loewis wrote:
If I were maintaining the Windows port (which I'm not), I would dislike the solution because it would mean I have to learn scons...
It is only an alternative to learning a new tool for converting VC project files to nmake specific makefile.
I cannot make modifications to the projects in the IDE, because I would have to make the modifications in the scons files, not in the VC projects.
That's true. You have to make the modifications in the scons file, but that modifications (usually adding or removing some c module, or I'm missing something?) can be used by VC/cygwin/mgwin/*nix user... potentially.
Such a free solution is already available, through cygwin/mingw.
But that leave you with the original problem... makefiles for the free microsoft compiler...
However, this is free software, so if you are interested, feel free to contribute. If you want your contribution be accepted, be prepared to answer "yes" to the question "Are you going to maintain the build process for the next three years"?
If somebody volunteers to maintain such a build process, I would not object to having this process in parallel to the VC build process (to which I'm willing to contribute, for the next three years).
I'm not actually in the position to reply "yes" to that question, I have too few spare time... but you are tempting me... :-) It was just an alternative suggestion that come in my mind after having read previous threads. I've done some month ago a scratch scons script for VC6 and VC7 compilation of the core python dll, pythonw.exe and python.exe... I must take a look to my messy sandbox at works! --- Paolo Invernizzi
Paolo Invernizzi wrote:
If I were maintaining the Windows port (which I'm not), I would dislike the solution because it would mean I have to learn scons...
It is only an alternative to learning a new tool for converting VC project files to nmake specific makefile.
It's different. That tool would have to be written from scratch, which would be a large effort for a single person. Learning scons would be a relatively small effort for a relatively large group of people (not only immediate maintainers of the Windows port, but anybody contributing to it, also).
That's true. You have to make the modifications in the scons file, but that modifications (usually adding or removing some c module, or I'm missing something?) can be used by VC/cygwin/mgwin/*nix user... potentially.
The more typical modification is the addition of an extension module, which means adding a new target. That becomes more and more tricky these days, as these new targets often have prerequisites that are difficult to build themselves (e.g. finding an available copy of OpenSSL, invoking Perl to build OpenSSL, invoking nmake to build zlib, etc). I somewhat doubt that the scons-to-vcproj generator gets such complex build dependencies correct - at which point the maintainers would need to look into the inner workings of scons to find out if it really can represent the build step in all supported "output build procedures", and how to make scons do it correctly.
But that leave you with the original problem... makefiles for the free microsoft compiler...
That, of course, is not a problem for the majority of the Python-Windows contributors, who already have a copy of VC 7.1 (thanks to a generous offer earlier this year). So for whoever this is a problem, they would need to find a solution. They need to find a way today already (as Python does not provide nmake files out of the box at the moment, either). The solution does not need to materialize itself next week, as the release of Python 2.4 is still months away.
I've done some month ago a scratch scons script for VC6 and VC7 compilation of the core python dll, pythonw.exe and python.exe...
I must take a look to my messy sandbox at works!
You could also maintain this "outside" of the standard Python distribution, as some kind of "drop-in" zip file. That would put no obligation onto you - your users could either use it, or leave it (and we could advertise it as an alternative somewhere). Regards, Martin
Martin v. Loewis wrote:
The more typical modification is the addition of an extension module, which means adding a new target. That becomes more and more tricky these days, as these new targets often have prerequisites that are difficult to build themselves (e.g. finding an available copy of OpenSSL, invoking Perl to build OpenSSL, invoking nmake to build zlib, etc).
Ok. For what I have understood reading the PCbuild/readme.txt (I admit I never tried to build on win32 an *hard* module, like tk or bdb, or ssl), the building process of that modules is still mostly a manual job... "follow the Windows instructions for building the Sleepycat software"
I somewhat doubt that the scons-to-vcproj generator gets such complex build dependencies correct - at which point the maintainers would need to look into the inner workings of scons to find out if it really can represent the build step in all supported "output build procedures", and how to make scons do it correctly.
The VC project generated by scons simply binds the IDE build command to scons itself, so when the IDE need to build something, it actually launch scons, which can handle a lot of mutual dependend target easily. Well, summarizing all, I can try some *non trivial* build process, like the python exes plus core dll, plus out-of-the-box modules, plus OpenSSL or bdb, and see what can be done with it... I'll post something as soon as I've done some tries. --- Paolo Invernizzi
Paolo Invernizzi wrote:
Ok. For what I have understood reading the PCbuild/readme.txt (I admit I never tried to build on win32 an *hard* module, like tk or bdb, or ssl), the building process of that modules is still mostly a manual job... "follow the Windows instructions for building the Sleepycat software"
It depends: yes for tk and sleepycat, no for ssl and bzip2.
I'll post something as soon as I've done some tries.
Please keep us posted. It would be good if it involved no more manual intervention than the current process; it would be a plus if the manual intervention would be reduced. It would also be a plus if you could figure out some of the pending issues while you are at it, like how to stop the linker warnings when linking _bsddb.pyd :-) Regards, Martin
Martin v. Loewis wrote:
Please keep us posted. It would be good if it involved no more manual intervention than the current process; it would be a plus if the manual intervention would be reduced.
Ok.
It would also be a plus if you could figure out some of the pending issues while you are at it, like how to stop the linker warnings when linking _bsddb.pyd :-)
Ok ;-) -- Paolo Invernizzi
On Mon, 29 Dec 2003, Alex Martelli wrote:
On Monday 29 December 2003 05:06 pm, Martin v. Loewis wrote: ...
It might be possible to write a generator that produces a makefile automatically from the VC.NET project files; contributions
At the time of Visual Studio 6, such a "generator" had been written by Microsoft, and was part of the VS6 package -- i.e., you could produce and save a makefile for the project you had loaded. Is this no more the case for the current release of Visual Studio...?
Alex
_______________________________________________ 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/logistix%40cathoderaymissi...
Yes, they removed that functionality (or at least I wasn't able to find it). I used Visual Studio 6.0 to generate a good makefile in my tests. In VC 7.1, you can feed the project file into the compiler via a command line flag. I think you needed to use the GUI to build in 6.0, so MS provided the makefile export feature for people who wanted to do automated builds and other stuff where you couldn't rely on the gui. So the feature became obsolete from MS's perspective. Unfortunately, I don't think the command-line compilers in the SDK will accept a Visual Studio project file.
At 04:27 PM 12/29/03 +0100, Martin v. Loewis wrote:
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages.
Was the question of mingw32-built extensions ever resolved? That is, will we be able to build extensions for the standard Windows Python using the distutils' "mingw32" compiler, as is possible with Python 2.2? If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test. I have several Pyrex and C extensions of varying vintage that I can use for such a test.
Phillip J. Eby wrote:
Was the question of mingw32-built extensions ever resolved? That is, will we be able to build extensions for the standard Windows Python using the distutils' "mingw32" compiler, as is possible with Python 2.2?
I don't know; I don't use mingw32. OTOH, I cannot see what the problem might be - except that you will have to link with msvcr71.dll at the end, not with msvcrt40.dll.
If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test.
Sure: Please try my installer at http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi Notice that this doesn't include msvcr71.dll, which I could provide in private. It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also. Regards, Martin
Martin v. Loewis wrote:
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
Some googling shows there is hope: http://sources.redhat.com/ml/cygwin-announce/2003-09/msg00089.html 2003-06-18 Earnie Boyd <earnie@users.sf.net> * Makefile.in (LIBS): Add new MSVCRT libraries libmsvcr70 and libmsvcr71, including debug versions. (msvcr70.def, msvcr70d.def, msvcr71.def, msvcr71.def): New targets. So atleast the part of linking with msvcr71.dll should be possible. As I said, I cannot imagine what else might be a problem. Regards, Martin
At 05:43 PM 12/29/03 +0100, Martin v. Loewis wrote: OTOH, I cannot see what the problem might be - except that you will
have to link with msvcr71.dll at the end, not with msvcrt40.dll.
If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test.
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
Notice that this doesn't include msvcr71.dll, which I could provide in private.
Please do.
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
Actually, one generates that by using dlltool and various other programs to extract a .def file from python2x.dll. I haven't generated one in ages, so I'm going to have to dig back up how to do that. The rest is handled by the distutils, pretty much. I don't think there's actually any direct linking to the MS VC runtime, anyway, if one is only using Python API calls. But I guess I'll find out. Hopefully I'll have enough clock cycles to spare on Thursday to get everything set up and tested.
"Phillip J. Eby" <pje@telecommunity.com> writes:
The rest is handled by the distutils, pretty much. I don't think there's actually any direct linking to the MS VC runtime, anyway, if one is only using Python API calls. But I guess I'll find out.
One thing that I imagine does need looking at is modifying distutils to check whether Python was built with VC7.1, and if so add a -lmsvcr71 flag to the gcc command line when compiling with mingw. This can be hacked by hand, but only at the expense of making setup.py version-specific (or doing your own test in setup.py). I don't know if Martin has already done this, but it needs doing. I'm not a distutils expert, but I am willing to look at it in the longer term. BTW, on another note, which 3rd party package developers have access to MSVC7.1, or can build with Mingw? Has anyone surveyed this? I, for one, have installed the following packages which have extension modules involved: cx_Oracle mxBase PIL pygame (not used much) win32all twisted wxPython pyXML Metakit If there wasn't a Windows binary version for 2.4 produced, this would cause me problems. At the very least, I'd suggest a warning post on c.l.p and c.l.p.announce, something to the effect of "Python 2.4 will be built with MSVC 7.1. Extension developers supplying binary distributions for Windows will need some way of building MSVC 7.1 compatible modules (MSVC 7.1 itself, or a recent version of the free Mingw compiler package) to continue providing binries." Paul. -- This signature intentionally left blank
Paul Moore wrote:
I don't know if Martin has already done this, but it needs doing. I'm not a distutils expert, but I am willing to look at it in the longer term.
I haven't changed any Python file at all in the process of compiling with VC 7.1. However, Python (since 2.3) indicates the compiler used to build it in sys.version; I believe this could be used as an indication to find out whether it was build with VC6 or VC7.1 (dunno whether it could also tell apart 7.0 and 7.1).
If there wasn't a Windows binary version for 2.4 produced, this would cause me problems.
Python 2.4 is still months ahead, I expect more copies of VC 7.1 being available by that time (unless Microsoft releases the next compiler version before that - but they are unlikely to do so until the very end of 2004).
At the very least, I'd suggest a warning post on c.l.p and c.l.p.announce, something to the effect of "Python 2.4 will be built with MSVC 7.1. Extension developers supplying binary distributions for Windows will need some way of building MSVC 7.1 compatible modules (MSVC 7.1 itself, or a recent version of the free Mingw compiler package) to continue providing binries."
I expect the word will spread quickly; again, there is plenty of time to prepare for that. Regards, Martin
Martin v. Loewis wrote:
I believe this could be used as an indication to find out whether it was build with VC6 or VC7.1 (dunno whether it could also tell apart 7.0 and 7.1).
For a version built with VC7.1 the sys.version is: 2.4a0 (#0, Dec 15 2003, 17:22:56) [MSC v.1310 32 bit (Intel)] If I remember well, for VC7.0 it's [MSC v.1300 bit (Intel)] --- Paolo Invernizzi
"Martin v. Loewis" <martin@v.loewis.de> writes:
Paul Moore wrote:
I don't know if Martin has already done this, but it needs doing. I'm not a distutils expert, but I am willing to look at it in the longer term.
I haven't changed any Python file at all in the process of compiling with VC 7.1. However, Python (since 2.3) indicates the compiler used to build it in sys.version; I believe this could be used as an indication to find out whether it was build with VC6 or VC7.1 (dunno whether it could also tell apart 7.0 and 7.1).
I have a patch which seems to do the right thing with respect to adding "-lmsvcr71" to the GCC link command. The resulting build looks OK, and building a simple extension works fine. Apparently, however, Phillip J. Eby got a working DLL without needing this. And indeed I have no problems omitting the -lmsvcr71. So we don't have a real example of the "potential issue" with mismatched MSVC runtimes. Nevertheless, if you do "objdump -p myext.pyd" and look at the import tables, you do see that runtime symbols are satisfied from msvcrt without the -l flag, and from msvcr71 with it (apart from abort, which is always from msvcrt, which seems to be a peculiarity of how the mingw startup code is linked). I've uploaded it to SourceForge (http://www.python.org/sf/870382) and assigned it to you. I hope that's OK. Paul.
At 02:57 PM 1/4/04 +0000, Paul Moore wrote:
I have a patch which seems to do the right thing with respect to adding "-lmsvcr71" to the GCC link command.
The resulting build looks OK, and building a simple extension works fine. Apparently, however, Phillip J. Eby got a working DLL without needing this. And indeed I have no problems omitting the -lmsvcr71. So we don't have a real example of the "potential issue" with mismatched MSVC runtimes. Nevertheless, if you do "objdump -p myext.pyd" and look
Aha, so *that*'s the option I needed ("private headers" didn't look like something to do with dependencies). Dumping my kjbuckets.pyd, I got: DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To c1f8 36 __dllonexit c208 147 _errno c214 510 abort c21c 522 calloc c228 537 fflush c234 547 fputc c23c 552 free c244 560 fwrite c250 603 malloc c25c 636 sprintf I didn't think kjbuckets used that many C functions. Apparently there are lots of debugging prints. protocols/_speedupds.pyd had much fewer: DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To 9258 36 __dllonexit 9268 147 _errno 9274 510 abort 927c 537 fflush 9288 552 free 9290 603 malloc and ZODB 4's _persistence.pyd has: DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To 6200 36 __dllonexit 6210 108 _assert 621c 147 _errno 6228 510 abort 6230 537 fflush 623c 552 free 6244 603 malloc 6250 666 time So it really does appear that the mscvcr71 linkage would be a very good idea.
at the import tables, you do see that runtime symbols are satisfied from msvcrt without the -l flag, and from msvcr71 with it (apart from abort, which is always from msvcrt, which seems to be a peculiarity of how the mingw startup code is linked).
Do you think that's likely to cause any issues?
"Phillip J. Eby" <pje@telecommunity.com> writes:
at the import tables, you do see that runtime symbols are satisfied from msvcrt without the -l flag, and from msvcr71 with it (apart from abort, which is always from msvcrt, which seems to be a peculiarity of how the mingw startup code is linked).
Do you think that's likely to cause any issues?
I can't prove that linking *anything* via msvcrt causes a problem. And a quick test shows that if user code calls malloc/free/abort, then those are linked from msvcr71. So it's only if the runtime calls the function, but your code doesn't, that the msvcrt version is used. Which is precisely when it doesn't matter (I think). So no, it won't cause any issues as far as I can see. Paul. -- This signature intentionally left blank
At 12:02 PM 12/30/03 +0000, Paul Moore wrote:
One thing that I imagine does need looking at is modifying distutils to check whether Python was built with VC7.1, and if so add a -lmsvcr71 flag to the gcc command line when compiling with mingw. This can be hacked by hand, but only at the expense of making setup.py version-specific (or doing your own test in setup.py).
No changes needed in either the distutils or setup.py, at least on my machine as of this evening. Apparently mingw is smart enough to figure this out on its own. Yay! Of course, I haven't exactly made an exhaustive test that *all* extensions are compilable with mingw, but I'm at least happy that all of the extensions I normally build for Windows are okay.
"Martin v. Loewis" <martin@v.loewis.de> writes:
OTOH, I cannot see what the problem might be - except that you will have to link with msvcr71.dll at the end, not with msvcrt40.dll.
There's an issue with mingw using malloc/free from msvcrt in its startup code - by the time msvcr71 gets linked in, the startup code has already resolved these two to msvcrt. I believe this is (nearly) resolved. Also, I've never seen a real problem caused by this, just dire hearsay about problems using incompatible runtimes...
If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test.
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
Does this install cleanly alongside a "production" Python 2.3? Ie, will it leave the meaning of the "python" command, and command line associations for .py files, etc, unchanged? As a test install, I'd like it to have no effect on my main Python (I have no test machine to install on separately).
Notice that this doesn't include msvcr71.dll, which I could provide in private.
Not a problem for me - I have this.
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
The appropriate library is indeed supplied with mingw. Paul. -- This signature intentionally left blank
Paul Moore <pf_moore@yahoo.co.uk> writes:
"Martin v. Loewis" <martin@v.loewis.de> writes:
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
Does this install cleanly alongside a "production" Python 2.3? Ie, will it leave the meaning of the "python" command, and command line associations for .py files, etc, unchanged?
No, it changes the associations for .py files. It would be useful to have the option to create no associations. As a workaround, installing the MSI file, and afterwards simply reinstalling python-2.3.3.exe seems to work fine. Thomas
Thomas Heller <theller@python.net> writes:
No, it changes the associations for .py files. It would be useful to have the option to create no associations.
Agreed, that would be useful. (More generally, if there's anything else needed to install a second Python version which is never used by default, but only used when explicitly requested, that would be useful too.) Hmm, for example, does the installer set the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\python.exe That's what makes the command "python" work at the console prompt. Maybe just a single option in the installer, "Make this the default version of Python", which is true by default, would be best. This could control file associations, App Paths, and anything else related.
As a workaround, installing the MSI file, and afterwards simply reinstalling python-2.3.3.exe seems to work fine.
Yup, that's a good workaround. Paul. -- This signature intentionally left blank
Paul Moore wrote:
Hmm, for example, does the installer set the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\python.exe
Yes, it does.
Maybe just a single option in the installer, "Make this the default version of Python", which is true by default, would be best. This could control file associations, App Paths, and anything else related.
Authoring new user interface interface is a tedious task. It is much easier to just have a public property, so you would have to install it as msiexec.exe python2.4.0.msi DEFAULTPYTHON=1 Regards, Martin
"Martin v. Loewis" <martin@v.loewis.de> writes:
Paul Moore wrote:
Hmm, for example, does the installer set the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\python.exe
Yes, it does.
Maybe just a single option in the installer, "Make this the default version of Python", which is true by default, would be best. This could control file associations, App Paths, and anything else related.
Authoring new user interface interface is a tedious task. It is much easier to just have a public property, so you would have to install it as
msiexec.exe python2.4.0.msi DEFAULTPYTHON=1
That sounds good enough - I know little about MSI, so when you say "public property" it doesn't mean much to me. But if it translates to "command line option with no GUI interface" then I have no problem at all with this - it's for advanced users only, so that's not a problem. Paul. -- This signature intentionally left blank
Paul Moore wrote:
That sounds good enough - I know little about MSI, so when you say "public property" it doesn't mean much to me. But if it translates to "command line option with no GUI interface" then I have no problem at all with this - it's for advanced users only, so that's not a problem.
Meanwhile, I have done both: I had to add an "Advanced" dialog, anyway to support selection of ALLUSERS (or just me). Still, with public properties, configuration in "unattended installation" (ie. no or restricted GUI) becomes possible, so I leave the public property in. I'll release an updated installer shortly. Regards, Martin
[Paul Moore wrote]
msiexec.exe python2.4.0.msi DEFAULTPYTHON=1
That sounds good enough - I know little about MSI, so when you say "public property" it doesn't mean much to me. But if it translates to "command line option with no GUI interface" then I have no problem at all with this - it's for advanced users only, so that's not a problem.
The install notes for ActivePython (which uses an MSI installer) show some of the things you can do with an MSI installer. The discussion for the ActivePython installer might shed some light, if you care: http://aspn.activestate.com/ASPN/docs/ActivePython/2.3/UserGuide/install.htm... Cheers, Trent -- Trent Mick TrentM@ActiveState.com
Paul Moore wrote:
Does this install cleanly alongside a "production" Python 2.3? Ie, will it leave the meaning of the "python" command, and command line associations for .py files, etc, unchanged?
No. It will overwrite the associations, and, upon uninstallation, it will entirely remove them. OTOH, it does install into a separate folder, and it creates shortcuts in a separate start menu folder.
As a test install, I'd like it to have no effect on my main Python (I have no test machine to install on separately).
You could generate such an installer yourself, setting a variable in msi.py. However, I can make installation of the shortcuts optional, in future builds of the installer (to be enabled through a public MSI property). Regards, Martin
At 05:43 PM 12/29/03 +0100, Martin v. Loewis wrote:
Phillip J. Eby wrote:
Was the question of mingw32-built extensions ever resolved? That is, will we be able to build extensions for the standard Windows Python using the distutils' "mingw32" compiler, as is possible with Python 2.2?
I don't know; I don't use mingw32.
OTOH, I cannot see what the problem might be - except that you will have to link with msvcr71.dll at the end, not with msvcrt40.dll.
If this hasn't been resolved, and somebody can send me a binary for a .NET-built Python, I'll be happy to test.
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
I just had a chance to try this out. One problem: pyconfig.h is missing from the installation. I copied over my pyconfig.h from Python 2.2, and was able to compile all my target extensions using the distutils 'mingw32' compiler selection. However, they crash the interpreter immediately upon import.
Notice that this doesn't include msvcr71.dll, which I could provide in private.
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
I'm guessing that this is related to the coredumps. I probably need to update my cygwin installation. Note that one doesn't explicitly link the msvcrt40 with earlier Pythons, so finding out how to change it to the 71 version is going to be... interesting. Will let you know what I come up with.
(and there was much rejoicing...) At 10:57 PM 1/3/04 -0500, Phillip J. Eby wrote:
At 05:43 PM 12/29/03 +0100, Martin v. Loewis wrote:
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
I just had a chance to try this out. One problem: pyconfig.h is missing from the installation.
I copied over my pyconfig.h from Python 2.2, and was able to compile all my target extensions using the distutils 'mingw32' compiler selection. However, they crash the interpreter immediately upon import.
But, they work now that I'm using the 2.4 pyconfig.h, copied and pasted from viewcvs. :) I didn't realize at first that it lived in 'PC' rather than 'Include' or 'PCBuild'.
It also does not include msvcr71.lib - I have no clue how you would get a copy of that. But then, somehow, msvcrt40.lib (or is it msvcrt40.a) must have gotten into mingw32 also.
I'm guessing that this is related to the coredumps. I probably need to update my cygwin installation. Note that one doesn't explicitly link the msvcrt40 with earlier Pythons, so finding out how to change it to the 71 version is going to be... interesting. Will let you know what I come up with.
As it turns out, it was unnecessary to do anything special, once I had the right pyconfig.h. I just used my normal setup.py, after upgrading to all the latest gcc/mingw/libtool/automake/etc. packages of my cygwin installation. I was able to build kjbuckets (Aaron Watters' data structure library, used by gadfly), an older version of ZODB 4's C '_persistence' support module, and the Pyrex-generated C speedups code for PyProtocols. All my tests for these and a handful of other modules passed. It looks like everything's cool for building 2.4 extensions with mingw. My only suggestion at this point would be to add 'pyconfig.h' to be installed in Python24/include. It'd be nice to throw in the libs/libpython24.a file, too, but it's big (603K) and I guess everybody who's been using mingw to this point either knows the procedure for making it by heart, or at least has a bookmark to one of the webpages that explains how to do it. (Such as http://sebsauvage.net/python/mingw.html )
Phillip J. Eby wrote:
It looks like everything's cool for building 2.4 extensions with mingw.
Very good! You should still double-check what DLLs your .pyds depend on; this is best done with depends.exe (if you have that). GNU objdump may also be able to do that.
My only suggestion at this point would be to add 'pyconfig.h' to be installed in Python24/include.
Done (see other message).
It'd be nice to throw in the libs/libpython24.a file, too, but it's big (603K) and I guess everybody who's been using mingw to this point either knows the procedure for making it by heart, or at least has a bookmark to one of the webpages that explains how to do it.
It would also require to have a certain amount of cygwin on the packaging machine, right? If the procedure could be modified to only use tools available on the target machine, I could look into generating that library on installation time. Alternatively, distutils could be modified to generate it on first use. Regards, Martin
At 12:42 PM 1/4/04 +0100, Martin v. Loewis wrote:
Phillip J. Eby wrote:
It looks like everything's cool for building 2.4 extensions with mingw.
Very good! You should still double-check what DLLs your .pyds depend on; this is best done with depends.exe (if you have that).
Nope. Apparently that's part of the Visual C toolkit.
GNU objdump may also be able to do that.
Also nope. But I googled and found there's a 'cygcheck' that does basically the same thing. It shows that the .pyd's are still linking w/msvcrt.dll. :( I have no idea how to stop it, either. I don't know what effects this might have, although clearly it hasn't stopped the extensions I built from working. But none of the extensions I tried do anything with e.g. file descriptors, raw memory allocation, or floating point math, and I'd assume that those are the areas most likely to have issues.
It'd be nice to throw in the libs/libpython24.a file, too, but it's big (603K) and I guess everybody who's been using mingw to this point either knows the procedure for making it by heart, or at least has a bookmark to one of the webpages that explains how to do it.
It would also require to have a certain amount of cygwin on the packaging machine, right?
If the procedure could be modified to only use tools available on the target machine, I could look into generating that library on installation time. Alternatively, distutils could be modified to generate it on first use.
Probably distutils would be the place to do it, since you may install Python long before you realize you'd like to make C extensions with mingw32. So, the needed tools (pexports.exe and dlltool.exe) wouldn't be available at install time. Doing it at first use has only the issue that the user would have to have rights to write to the Python24/libs directory, even if they're not planning to install anything there. So, distutils would have to build the library in the local build/ directory if it couldn't write to the libs directory. Hm. Really, it begins to sound as though there should either be a separate distutils command to build the library, or just a script you can run to build and/or install the library. I'll consider writing something -- at least a doc patch, if not a script -- for 2.4.
At 11:00 AM 1/4/04 -0500, Phillip J. Eby wrote:
Hm. Really, it begins to sound as though there should either be a separate distutils command to build the library, or just a script you can run to build and/or install the library. I'll consider writing something -- at least a doc patch, if not a script -- for 2.4.
After a bit more research, I have a short Python script to prepare a Windows Python installation for using the mingw32 compiler option. It does not require a separate download of the 'pexports' program; it requires only that the 'nm' and 'dlltool' executables (installed with the Cygwin 'binutils' package) are available on the system PATH, and that the user running it have write access to the PythonNN/libs directory. Should this, or something like it, be distributed with Windows Python? If so, where in the distribution should it go? Should I create a SF patch for this? #=== mingw_setup.py """Create pythonNN.def and libpythonNN.a in 'PythonNN/libs' directory This script makes it possible to use the MinGW compiler tools to build C extensions that work with the standard Windows Python distribution. Before running, you should have installed the MinGW compiler toolset, and placed its 'bin' directory on your PATH. An easy way to do this is to install Cygwin's "binutils", "gcc", and "mingw-*" packages, then run this script from the Cygwin shell. (Be sure to use *Windows* Python, not Cygwin python!) Once this script has been run, you should be able to build extensions using distutils in the standard way, as long as you select the 'mingw32' compiler, and the required tools are on your PATH. See the "Installing Python Modules" manual for more information on selecting a compiler. """ from distutils.spawn import find_executable from distutils.sysconfig import get_config_var from distutils import __file__ as distutils_file import os, re, sys if sys.platform=='cygwin': print "Please run this script using Windows python,", print "not Cygwin python. E.g, try:" print print "/cygdrive/c/PythonNN/python", " ".join(sys.argv) print print "(where NN is the major/minor python version number)" sys.exit() basename = 'python%d%d' % sys.version_info[:2] libs_dir = os.path.join(get_config_var('prefix'),'libs') lib_file = os.path.join(libs_dir,basename+'.lib') def_file = os.path.join(libs_dir,basename+'.def') ming_lib = os.path.join(libs_dir,'lib%s.a' % basename) distutils_cfg = os.path.join(os.path.dirname(distutils_file),'distutils.cfg') export_match = re.compile(r"^_imp__(.*) in python\d+\.dll").match nm = find_executable('nm') dlltool = find_executable('dlltool') if not nm or not dlltool: print "'nm' and/or 'dlltool' were not found;" print "Please make sure they're on your PATH." sys.exit() nm_command = '%s -Cs %s' % (nm, lib_file) print "Building", def_file, "using", nm_command f = open(def_file,'w') print >>f, "LIBRARY %s.dll" % basename print >>f, "EXPORTS" nm_pipe = os.popen(nm_command) for line in nm_pipe.readlines(): m = export_match(line) if m: print >>f, m.group(1) f.close() exit = nm_pipe.close() if exit: print "nm exited with status", exit print "Please check that", lib_file, "exists and is valid." sys.exit() print "Building",ming_lib,"using",dlltool dlltool_pipe = os.popen( "%s --dllname %s.dll --def %s --output-lib %s" % (dlltool, basename, def_file, ming_lib) ) dlltool_pipe.readlines() exit = dlltool_pipe.close() if exit: print "dlltool exited with status", exit print "Unable to proceed." sys.exit() print print "Installation complete. You may wish to add the following" print "lines to", distutils_cfg, ':' print print "[build]" print "compiler = mingw32" print print "This will make the distutils use MinGW as the default" print "compiler, so that you don't need to configure this for" print "every 'setup.py' you run."
Phillip J. Eby wrote:
Should this, or something like it, be distributed with Windows Python? If so, where in the distribution should it go? Should I create a SF patch for this?
I would put it into Tools/scripts; for that, no SF patch would be necessary. However, I would think that distutils should find out whether the essential libraries are present, and suggest running a script if they are not - so please do submit a patch for that (which then should include your script). Regards, Martin
Phillip J. Eby wrote:
I just had a chance to try this out. One problem: pyconfig.h is missing from the installation.
I copied over my pyconfig.h from Python 2.2, and was able to compile all my target extensions using the distutils 'mingw32' compiler selection.
This is now fixed with today's installer: http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.12421.msi It might be useful to try again.
I'm guessing that this is related to the coredumps. I probably need to update my cygwin installation. Note that one doesn't explicitly link the msvcrt40 with earlier Pythons, so finding out how to change it to the 71 version is going to be... interesting. Will let you know what I come up with.
I believe mingw has a default crt it links with, and you probably need to change that. Regards, Martin
"Martin v. Loewis" <martin@v.loewis.de> writes:
Sure: Please try my installer at
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python2.4.0.msi
One item I noticed with this installer (I used the build 12421, which I believe is the latest) is that there is no ability to specify where you want the start menu entries to go. I regularly, with Python 2.3, move them from "All Programs\Python 2.3" to "All Programs\Programming \Python 2.3" I can manually move the start menu entries, but doing it via the installer means (a) that the uninstaller knows where to remove them from, and (b) other extensions such as win32all, can find them to add their own extras. Paul. -- This signature intentionally left blank
Paul Moore wrote:
One item I noticed with this installer (I used the build 12421, which I believe is the latest) is that there is no ability to specify where you want the start menu entries to go. I regularly, with Python 2.3, move them from "All Programs\Python 2.3" to "All Programs\Programming \Python 2.3"
I don't know how to do this. Does the current (Wise) installer offer user interface for this? Do you know of other .msi-based software that has that feature (and for which I might have the .msi package somewhere). Regards, Martin
Saturday, January 17, 2004, 7:19:29 PM, you wrote:
Paul Moore wrote:
One item I noticed with this installer (I used the build 12421, which I believe is the latest) is that there is no ability to specify where you want the start menu entries to go. I regularly, with Python 2.3, move them from "All Programs\Python 2.3" to "All Programs\Programming \Python 2.3"
I don't know how to do this. Does the current (Wise) installer offer user interface for this? Do you know of other .msi-based software that has that feature (and for which I might have the .msi package somewhere).
To do this, you'd have to treat MENUDIR the same way you treat TARGETDIR: Provide a default of [ProgramMenuFolder]Python 2.4 and provide a dialog to change it. I'm not aware of any MSI-based installers that offer this feature; the current "Windows User Experience" book says you should have critical shortcuts in the root of Programs and a subfolder only if absolutely necessary, so selecting a shortcut folder is kinda awkward... -- sig://boB http://foobob.com
Bob Arnson wrote:
To do this, you'd have to treat MENUDIR the same way you treat TARGETDIR: Provide a default of [ProgramMenuFolder]Python 2.4 and provide a dialog to change it. I'm not aware of any MSI-based installers that offer this feature; the current "Windows User Experience" book says you should have critical shortcuts in the root of Programs and a subfolder only if absolutely necessary, so selecting a shortcut folder is kinda awkward...
But isn't it a problem that [ProgramMenuFolder] depends on the value of ALLUSERS? I don't set ALLUSERS until the feature selection dialog is complete, so the magic computing ProgramMenuFolder certainly isn't invoked at the point I would show that dialog. However, a specific directory must be computed for the dialog to work, as the directory browser would have to show the existing items. It would be best if browsing for the shortcut folder, in the just-for-me case, would perform the same directory merging that the start menu does (i.e. combining the all users start menu with the current user's start menu, then perform modifications only in the current user's directories). I somewhat doubt this is possible at all. Regards, Martin
Sunday, January 18, 2004, 4:12:16 AM, you wrote:
But isn't it a problem that [ProgramMenuFolder] depends on the value of ALLUSERS? I don't set ALLUSERS until the feature selection dialog is complete, so the magic computing ProgramMenuFolder certainly isn't invoked at the point I would show that dialog. However, a specific directory must be computed for the dialog to work, as the directory browser would have to show the existing items.
That's true. Erg...I now remember facing the same problem at work, though in this case it's to give different Start menu folders for different products. We fixed it by post-processing the different MSIs. You can't even use a property in the Directory table DefaultDir column. I hacked the Python MSI to add a custom action to set MENUDIR and it works. So you could have a text box on the Advanced dialog that defaults to "Python 2.4" and can be overridden. Of course, then you have to worry about short file names... -- sig://boB http://foobob.com
Bob Arnson wrote:
You can't even use a property in the Directory table DefaultDir column. I hacked the Python MSI to add a custom action to set MENUDIR and it works. So you could have a text box on the Advanced dialog that defaults to "Python 2.4" and can be overridden. Of course, then you have to worry about short file names...
But can you use that also to address a subfolder? I.e. if that were to contain a backslash ("Programming\Python 2.4" instead of "Python 2.4"), would that work? Regards, Martin
Sunday, January 18, 2004, 3:57:45 PM, you wrote:
But can you use that also to address a subfolder? I.e. if that were to contain a backslash ("Programming\Python 2.4" instead of "Python 2.4"), would that work?
Yes, that works. Surprised me too.<g> I would have expected a problem with MSI creating the subdirectory automatically. However, there is some problem with my hack because it doesn't remove the shortcuts at uninstall time. I authored the custom action into the execute sequence, so it should have run at uninstall time too, so I'm not sure what's wrong... -- sig://boB http://foobob.com
"Martin v. Löwis" <martin@v.loewis.de> writes:
Paul Moore wrote:
One item I noticed with this installer (I used the build 12421, which I believe is the latest) is that there is no ability to specify where you want the start menu entries to go. I regularly, with Python 2.3, move them from "All Programs\Python 2.3" to "All Programs\Programming \Python 2.3"
I don't know how to do this.
Unfortunately, I have no experience with MSI installers, so I can't help.
Does the current (Wise) installer offer user interface for this?
Yes, that's how I was aware of it. It gives a (fairly standard - but I don't know if MSI based installers have it) dialog, listing the subfolders of the start menu (Accessories, etc) and a default of "Python 2.3". You can override this, and if you include backslashes (as in Programming\Python 2.3) then that translates to a subfolder. There's no GUI way of specifying a subfolder, though.
Do you know of other .msi-based software that has that feature (and for which I might have the .msi package somewhere).
No, I'm afraid I don't. I tend not to be particularly aware of what installer technology particular software uses. Paul. -- This signature intentionally left blank
"Paul Moore" <pf_moore@yahoo.co.uk> wrote in message news:7jzpbfns.fsf@yahoo.co.uk...
"Martin v. Löwis" <martin@v.loewis.de> writes:
Paul Moore wrote:
One item I noticed with this installer (I used the build 12421, which I believe is the latest) is that there is no ability to specify where you want the start menu entries to go. I regularly, with Python 2.3, move them from "All Programs\Python 2.3" to "All Programs\Programming \Python 2.3"
I don't know how to do this.
Unfortunately, I have no experience with MSI installers, so I can't help.
Part of how I judge games (and other software - but I install and remove more demos than anything else) is by whether the installer allows me to put start menu entries in a directory/group of my own naming under my current start/games group or whether it imperialisticly insists on adding a new top level entry like egocorp/. (Microsoft itself being an example of one of the latter :-(. So, although I am personally happy with pythonx.y/, I agree it would be preferable to give people a choice. But I have no idea of the mechanics. I know that InstallShield can do this, but have no idea if they now use msi or not. Another related matter. Under XP, programs can be installed so they only work for admin user (ugh), so that they are only obviously accessible by admin (through desktop icon and start menu) but actually work for any account if one uses explorer to find and double click on executable, or so that they are visible and work from any account. Except for admin only programs, which python is not, I prefer latter (and will test for with latest installer soon on new xp system). Terry J. Reedy
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 04:27 PM 12/29/03 +0100, Martin v. Loewis wrote:
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages.
Was the question of mingw32-built extensions ever resolved? That is, will we be able to build extensions for the standard Windows Python using the distutils' "mingw32" compiler, as is possible with Python 2.2?
It is (pretty close) to being solved - recent versions of mingw32 allow building with msvcr71 via a -lmsvcr71 flag. However, last time I tried this, the generated linker commands didn't quite work, and needed a bit of fiddling. I have the latest mingw, though, so I can easily try this. Paul -- This signature intentionally left blank
Martin v. Loewis wrote:
In my own sandbox, I have prepared project files for VC.NET.
Unless there are any strong objections, I'd like to switch over to VC.NET shortly, disabling VC6 builds. In the process, I will also update the build dependencies to more recent versions of several packages.
Ach du Sch***e. I don't want to buy another M$ compiler. Is there a freeware alternative? ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
I don't want to buy another M$ compiler. Is there a freeware alternative?
Ten core Python developers received a free VC7.1 copy from Microsoft. Maybe someone who hasn't opened theirs yet is willing to step down? MS also alluded to a free downloadable compiler, but I haven't tracked it down yet. And of course theer's always mingw (or whatever it's called). --Guido van Rossum (home page: http://www.python.org/~guido/)
Ten core Python developers received a free VC7.1 copy from Microsoft. Maybe someone who hasn't opened theirs yet is willing to step down?
Maybe there are a few more available?
I'm not going to ask. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I don't want to buy another M$ compiler. Is there a freeware alternative?
Ten core Python developers received a free VC7.1 copy from Microsoft. Maybe someone who hasn't opened theirs yet is willing to step down?
MS also alluded to a free downloadable compiler, but I haven't tracked it down yet. And of course theer's always mingw (or whatever it's called).
If there is a way I can provide Windows binaries, and I can do some interactive debugging, I'm willing to switch tools, sure. ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
MS also alluded to a free downloadable compiler, but I haven't tracked it down yet. And of course theer's always mingw (or whatever it's called).
If there is a way I can provide Windows binaries, and I can do some interactive debugging, I'm willing to switch tools, sure.
I doubt the free compiler provides any interactive debugging support. So you either have to continue to use VC6, or switch to VC.NET, or switch to Borland C, or use gdb (on cygwin). Regards, Martin
There is the "Microsoft Visual C++ .NET 2003 Standard" that is cheap, £90. Fully set of debugger and project tools, just won't do release builds. Barry At 01-01-2004 12:44, Martin v. Loewis wrote:
Christian Tismer wrote:
MS also alluded to a free downloadable compiler, but I haven't tracked it down yet. And of course theer's always mingw (or whatever it's called).
If there is a way I can provide Windows binaries, and I can do some interactive debugging, I'm willing to switch tools, sure.
I doubt the free compiler provides any interactive debugging support. So you either have to continue to use VC6, or switch to VC.NET, or switch to Borland C, or use gdb (on cygwin).
Regards, Martin
_______________________________________________ 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/nospam%40barrys-emacs.org
Christian Tismer wrote:
Ach du Sch***e. I don't want to buy another M$ compiler. Is there a freeware alternative?
Depends on what you want to do. If all you want to do is build extensions, this should be possible with mingw. Actually, with some work, it might be possible to build all of Python with mingw. As for freeware alternatives: Linux is a good alternative to Windows, too :-) Regards, Martin
Martin v. Loewis wrote: [CT doesn't want to spend money on a new compiler]
Depends on what you want to do. If all you want to do is build extensions, this should be possible with mingw. Actually, with some work, it might be possible to build all of Python with mingw.
As for freeware alternatives: Linux is a good alternative to Windows, too :-)
The problem is: On Windows, and with VC++6.0, I really can fly, while on Linux I'm so-so. It would be a shame if I had to pass Stackless Windows support over to someone else, just because we changed compilers ;-) best wishes for the new year -- chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
participants (18)
-
"Martin v. Löwis" -
Alex Martelli -
Barry Scott -
Bob Arnson -
Christian Tismer -
Guido van Rossum -
kbk＠shore.net -
logistix -
Mark Hammond -
Martin v. Loewis
-
Mike Rovner -
Paolo Invernizzi -
Paul Moore -
Phillip J. Eby -
Terry Reedy -
Thomas Heller -
Tim Peters -
Trent Mick