Re: Windows install to custom location after building from source
BTW what are your feelings on a patch to msi.py to change the names of the directories it's looking for to pick up the Tk licenses? It's a bit of a grey area since the only canonical reference I can find is the externals checkout from within tools\buildbot: you might as well argue that it's *that* which should be changed. Never touch a running system :-) If I can leave the tcl directories where I have them, and just check them out a second time (or perhaps just the license), that would be fine with me. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: BTW what are your feelings on a patch to msi.py to change the names of the directories it's looking for to pick up the Tk licenses? It's a bit of a grey area since the only canonical reference I can find is the externals checkout from within tools\buildbot: you might as well argue that it's *that* which should be changed. Never touch a running system :-) If I can leave the tcl directories where I have them, and just check them out a second time (or perhaps just the license), that would be fine with me. OK; I've added a step to my process which does a svn export with the other name, specifying a depth of files-only. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: First, it relies on config.py whose existence msi.py optionally ignores. Feel free to create a patch for that. http://bugs.python.org/issue5467 TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: I also see that it fails to add custom actions into InstallExecuteSequence. I find that puzzling - apparently, it tries to merge the twice. Are you sure you didn't run it twice? It will certainly fail the second time. Just to confirm: I'm certainly only running this once. Still getting the same errors. Log attached for completeness. However, the .msi installs (and Python runs) without issue on a virgin VirtualXP. And it passes the basic test suite ok. This isn't surprising if it's just a case of I've already done that; I'm not doing it again as you suggest. But I'm not sure what's causing it. Not worth worrying about too much, I expect. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Tim Golden wrote: However, the .msi installs (and Python runs) without issue on a virgin VirtualXP. And it passes the basic test suite ok. I lied. test_zipfile fails because the new(ish) zipdir.zip doesn't get carried across to the install. Patched in: http://bugs.python.org/issue5470 A couple of other tests fail (test_platform test_pep352) when running regrest, but I can't get them to fail otherwise. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Tim Golden wrote: Martin v. Löwis wrote: Just create an empty one. Won't quite work: merge tries to find full_current_version which is determined (if None) in msi.py from the rather involved current version stuff. Only if you don't pass an msi file on the command line. So I recommend that you do that. Latest attempt: merge.py runs but produces errors. Unfortunately I know next to nothing about what MSI's trying to do here, except in the most general sense that it's bringing auxiliary files into the main MSI database. I attach the merge.log output but I'll try to do some research to understand what's going on here in any case. In particular it's not clear to me whether the thing has worked but has just tripped up over some non-essential part, or whether these are real errors. (I really need to set up a virtual machine which doesn't have VS2008). For the record, running it by sticking execfile (merge) at the end of msi.py has the same effect. TJG Opened MSI Database: python-2.7.14312.msi Opened Merge Module: C:\Program Files\Common Files\Merge Modules\Microsoft_VC90_CRT_x86.msm Merging Table: ModuleSignature o Merging row: Microsoft_VC90_CRT_x86.0138F525_6C8A_333F_A105_14AE030B9A54 Merging Table: Directory Merging generated Directory actions into Database Table: AdminUISequence Merging Sequence Table: ModuleAdminExecuteSequence into Database Table: AdminExecuteSequence Base Action CostInitialize in AdminExecuteSequence table already exists in MSI. Using MSI action. Placing action WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 before CostInitialize Merging Sequence Table: ModuleAdvtExecuteSequence into Database Table: AdvtExecuteSequence Base Action MsiPublishAssemblies in AdvtExecuteSequence table already exists in MSI. Using MSI action. Merging generated Directory actions into Database Table: InstallUISequence Merging Sequence Table: ModuleInstallExecuteSequence into Database Table: InstallExecuteSequence Base Action CostInitialize in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action MsiPublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action AllocateRegistrySpace in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action InstallFiles in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action InstallFinalize in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action MsiUnpublishAssemblies in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action RemoveFiles in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action RemoveRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action. Base Action WriteRegistryValues in InstallExecuteSequence table already exists in MSI. Using MSI action. Placing action SxsUninstallCA after InstallFinalize Placing action WindowsFolder.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 before CostInitialize Placing action SxsInstallCA before AllocateRegistrySpace Merging Table: File o Merging row: ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 13 to 2695. o Merging row: nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 8 to 2690. o Merging row: nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 7 to 2689. o Merging row: nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 6 to 2688. o Merging row: ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 10 to 2692. o Merging row: ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 9 to 2691. o Merging row: ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 12 to 2694. o Merging row: ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54 * Changing ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54's Sequence Column from 11 to 2693. o Merging row:
Re: Windows install to custom location after building from source
I attach the merge.log output but I'll try to do some research to understand what's going on here in any case. In particular it's not clear to me whether the thing has worked but has just tripped up over some non-essential part, or whether these are real errors. (I really need to set up a virtual machine which doesn't have VS2008). AFAICT, it only complained about errors in merging _Validation. I'm not sure whether I get the same errors (I would have to check); those errors can safely be ignored. _Validation is only used if you want to validate the MSI file, and I think it complained because the data being merged are different than the data that were already there. This, in turn, is because the data already there are (or should be) the recommended values, whereas the CRT msm deviates from Microsoft's recommended values (IIRC). I also see that it fails to add custom actions into InstallExecuteSequence. I find that puzzling - apparently, it tries to merge the twice. Are you sure you didn't run it twice? It will certainly fail the second time. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: AFAICT, it only complained about errors in merging _Validation. I'm not sure whether I get the same errors (I would have to check); those errors can safely be ignored. Good. I also see that it fails to add custom actions into InstallExecuteSequence. I find that puzzling - apparently, it tries to merge the twice. Are you sure you didn't run it twice? It will certainly fail the second time. I'll double check. There was a point at which I was execfile-ing it from within msi.py *and* running it separately, but I thought I'd fixed that. BTW what are your feelings on a patch to msi.py to change the names of the directories it's looking for to pick up the Tk licenses? It's a bit of a grey area since the only canonical reference I can find is the externals checkout from within tools\buildbot: you might as well argue that it's *that* which should be changed. For my own part, I can run on a patched version quite easily so there's no real urgency for me. I'm just about at the point when I can put together a from-scratch instruction sheet for erstwhile Python-Windows developers to build Python pywin32 including installers from checkouts. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Gabriel Genellina wrote: En Fri, 06 Mar 2009 06:52:00 -0200, dan.erik.peter...@gmail.com escribió: I have succeeded in building Python 2.6.1 from source under Windows XP by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file both from the Visual C++ application as well as from the commandline [...] I would like to move this Python installation in a clean manner over to another location outside the unpackaged source directory (e.g. from C:\Python-2.6.1 to C:\custom_path\python). Is there already some automatic command that can perform this? If not, which files do I move where and what should the structure be? How do ensure all the Python code related to the install is byte-compiled and ready for use? Create an installer (pythonXXX.msi) and use it to install wherever you want. See Tools\msi in the source tree. If you built using VS2008 Express Edition, probably don't have cabarc.exe - download it from http://support.microsoft.com/kb/310618/en-us and make sure the bin directory is in your PATH before running msi.py A small caveat here: I've just done this myself and I had to patch one or two things very slightly. I have the htmlhelp libraries in a non-standard place and the make.bat helper file in the doc\ directory hardcodes its location. The patch from this tracker issue: http://bugs.python.org/issue2421 solves that (with the help of an env var). The other thing is that the instructions in the pcbuild/readme.txt and the corresponding code in Tools\buildbot\external-common.bat export the external tcl/tk libraries under the name tcl-8* and tk-8* whereas the msi.py code is expecting to find them under tcl8* and tk8*. In addition, msi.py is looking for a tix-* directory which doesn't seem to come from anywhere. I don't know if that constitutes a bug in msi.py or one in the pcbuild / external-common.bat or neither of the two. Happy to produce a patch if needed. In addition, the CVS version of pywin32 which I built in order to run the msi.py script has a small bug in genpy which prevents it from generating COM support in the way in which msi.py does it. I've reported it as issue 2672514 on the pywin32 tracker: http://sourceforge.net/tracker/index.php?func=detailaid=2672514group_id=78018atid=551954 Anyhow, at the end I have a working Python 2.7a0 running under Windows. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Tim Golden wrote: ... Anyhow, at the end I have a working Python 2.7a0 running under Windows. Do you mean 3.1a0? As far as I know, 2.7a0 requires the use of the time machine, as it is expected to be 3 months out. If you do get an installer built, even having a semi-official copy around for those of us not on the MS compiler upgrade train to do a little alpha (and/or beta) testing as well. --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
In addition, the CVS version of pywin32 which I built in order to run the msi.py script has a small bug in genpy which prevents it from generating COM support in the way in which msi.py does it. I'm using Python 2.4 to run msi.py; that has always worked fine for me. Regards, Martin P.S. Don't forget to run merge.py after msi.py -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Do you mean 3.1a0? As far as I know, 2.7a0 requires the use of the time machine, as it is expected to be 3 months out. The current trunk calls itself 2.7a0. I think you might be referring to 3.0a1. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: In addition, the CVS version of pywin32 which I built in order to run the msi.py script has a small bug in genpy which prevents it from generating COM support in the way in which msi.py does it. I'm using Python 2.4 to run msi.py; that has always worked fine for me. Interesting. Didn't even think of that. Well, it works ok with my micro-patches anyway. Regards, Martin P.S. Don't forget to run merge.py after msi.py What does the merge do? I can't find mention of it in the docs. Thanks for the input, by the way. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Scott David Daniels wrote: Tim Golden wrote: ... Anyhow, at the end I have a working Python 2.7a0 running under Windows. Do you mean 3.1a0? As far as I know, 2.7a0 requires the use of the time machine, as it is expected to be 3 months out. No; 2.7a0 is the version number of the svn HEAD. If you do get an installer built, even having a semi-official copy around for those of us not on the MS compiler upgrade train to do a little alpha (and/or beta) testing as well. There used to be nightly .msi builds, don't remember where; if Martin (or someone) doesn't chip in with something, I'll happily provide an unofficial build. In fact, I might do it anyway if I can get my act together. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
What does the merge do? I can't find mention of it in the docs. It merges the msvcrt merge module into the installer (and then monkey patches it, to revert the msm decision of setting ALLUSERS). I tried to integrate it originally as a step after creating the msi. Unfortunately, the merge object refused to open the database, claiming that the file is in use (even though I had closed it). Hence I need to processes. If you can figure out how to combine them into one, again, that would be much appreciated. If you don't merge the CRT, the resulting Python installation will fail on systems were a) VS 2008 is not installed (nor has the stand-alone CRT installer been run, nor has anything else been installed that comes with the CRT), and b) Python is installed for all users (else a private copy of msvcr90.dll gets installed) Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: What does the merge do? I can't find mention of it in the docs. It merges the msvcrt merge module into the installer (and then monkey patches it, to revert the msm decision of setting ALLUSERS). I tried to integrate it originally as a step after creating the msi. Unfortunately, the merge object refused to open the database, claiming that the file is in use (even though I had closed it). Hence I need to processes. If you can figure out how to combine them into one, again, that would be much appreciated. At the moment, I'm struggling to make it work at all :) First, it relies on config.py whose existence msi.py optionally ignores. I've created a dummy, based on the settings in msi.py. Then I get a COM error, reproduced below. I've got to go and do something else at the moment but I'll look into it afterwards. I'll dump the traceback here in case it rings any bells. TJG dump Opened Log Traceback (most recent call last): File merge.py, line 79, in module merge(msi, SharedCRT, TARGETDIR, modules) File merge.py, line 27, in merge m.OpenDatabase(msi) File COMObject Msm.Merge2.1, line 2, in OpenDatabase pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None, None, None, 0, -2147024786), None) [33419 refs] /dump TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
En Sun, 08 Mar 2009 18:08:50 -0200, Martin v. Löwis mar...@v.loewis.de escribió: What does the merge do? I can't find mention of it in the docs. It merges the msvcrt merge module into the installer (and then monkey patches it, to revert the msm decision of setting ALLUSERS). I tried to integrate it originally as a step merge.py attempts to import config.py but I can't find it... -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
merge.py attempts to import config.py but I can't find it... Just create an empty one. Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
First, it relies on config.py whose existence msi.py optionally ignores. Feel free to create a patch for that. File COMObject Msm.Merge2.1, line 2, in OpenDatabase pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None, None, None, 0, -2147024786), None) This is 0x8007006e; 0x6E, in turn, might be ERROR_OPEN_FAILED. Did you pass the file name of the MSI file? If not, it computed one, and may have done so incorrectly. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: merge.py attempts to import config.py but I can't find it... Just create an empty one. Won't quite work: merge tries to find full_current_version which is determined (if None) in msi.py from the rather involved current version stuff. I'm going to give up on this for tonight, but one possibility is to turn msi.py into an importable module and for msilib to import it and pull the config values from there. TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Just create an empty one. Won't quite work: merge tries to find full_current_version which is determined (if None) in msi.py from the rather involved current version stuff. Only if you don't pass an msi file on the command line. So I recommend that you do that. I'm going to give up on this for tonight, but one possibility is to turn msi.py into an importable module and for msilib to import it and pull the config values from there. Please, no. The only way I could accept that if merge.py would be run at the end of msi.py (i.e. merge.py disappears). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
Martin v. Löwis wrote: Just create an empty one. Won't quite work: merge tries to find full_current_version which is determined (if None) in msi.py from the rather involved current version stuff. Only if you don't pass an msi file on the command line. So I recommend that you do that. OK. I'm going to give up on this for tonight, but one possibility is to turn msi.py into an importable module and for msilib to import it and pull the config values from there. Please, no. The only way I could accept that if merge.py would be run at the end of msi.py (i.e. merge.py disappears). Understood. TJG -- http://mail.python.org/mailman/listinfo/python-list
Windows install to custom location after building from source
Hi all - I have succeeded in building Python 2.6.1 from source under Windows XP by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file both from the Visual C++ application as well as from the commandline using : vcbuild pcbuild.sln 'Release|Win32' This builds fine (allowing for errors in the build of modules like sql3 and the like where I have not fetched source code), and creates its products in-place in the source directory. My question/desire is : I would like to move this Python installation in a clean manner over to another location outside the unpackaged source directory (e.g. from C:\Python-2.6.1 to C:\custom_path\python). Is there already some automatic command that can perform this? If not, which files do I move where and what should the structure be? How do ensure all the Python code related to the install is byte-compiled and ready for use? I have Googled as best as I can but no luck. Thanks, Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
I suppose that what I am looking for is the Windows version of make install as we know it after running configure with -- prefix=custom_location --exec-prefix=custom_location flags and make on the Linux platform. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
dan.erik.peter...@gmail.com schrieb: I suppose that what I am looking for is the Windows version of make install as we know it after running configure with -- prefix=custom_location --exec-prefix=custom_location flags and make on the Linux platform. The Windows build system doesn't have anything related to make install. You have to assemble a distribution yourself or you have to create a MSI package. See Tools/msi/ Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
En Fri, 06 Mar 2009 06:52:00 -0200, dan.erik.peter...@gmail.com escribió: I have succeeded in building Python 2.6.1 from source under Windows XP by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file both from the Visual C++ application as well as from the commandline [...] I would like to move this Python installation in a clean manner over to another location outside the unpackaged source directory (e.g. from C:\Python-2.6.1 to C:\custom_path\python). Is there already some automatic command that can perform this? If not, which files do I move where and what should the structure be? How do ensure all the Python code related to the install is byte-compiled and ready for use? Create an installer (pythonXXX.msi) and use it to install wherever you want. See Tools\msi in the source tree. If you built using VS2008 Express Edition, probably don't have cabarc.exe - download it from http://support.microsoft.com/kb/310618/en-us and make sure the bin directory is in your PATH before running msi.py -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows install to custom location after building from source
On Mar 6, 11:21 am, Christian Heimes li...@cheimes.de wrote: dan.erik.peter...@gmail.com schrieb: I suppose that what I am looking for is the Windows version of make install as we know it after running configure with -- prefix=custom_location --exec-prefix=custom_location flags and make on the Linux platform. The Windows build system doesn't have anything related to make install. You have to assemble a distribution yourself or you have to create a MSI package. See Tools/msi/ Christian Thanks guys - Looks like I'll have to settle on building a distribution myself, as a solution based on MSI isn't in the cards ... so far, so good. Dan; -- http://mail.python.org/mailman/listinfo/python-list
