You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2007-11-18.20:23:38.708>created_at=<Date2007-11-15.15:23:54.243>labels= ['build', 'expert-installation']
title='make msi work the vs 2005(MSVC8)'updated_at=<Date2007-11-18.21:36:11.461>user='https://bugs.python.org/weck'
with vs 2003, msi.py get msvcr71.dll from msm. but with vs 2005, It's
better to extract msvcr80.dll from %VCINTALLDIR%\redist\x86
\Microsoft.VC80.CRT\. In addition, it seems to extract file from
Microsoft_VC80_CRT_x86.msm need upgrade MSI to 3.1, i am not sure.
I 'PCbuild' to 'PCbuild8' in msi.py and add extract_msvcr80, that will
make msi.py work with vs 2005.
I'm resetting the target version of all your MSVC patches to 2.6 + 3.0.
While we can't alter the compiler version of Python 2.5 I really like to
update to a new compiler for 2.6 and 3.0.
The patch looks fine but I've a small request. Could you please use a
global var PCBUILD instead of "PCBuild" / "PCBuild8" and change the
dependencies to use either MSVCR 71 or 80 depending on the content of
the var. This way the msi module can handle both versions.
loewis commented on Nov 15, 2007
loewismannequin
Mannequin
More actions
I'm opposed to this patch. Any change to the MSI build process should
only be made when/after the default compiler for Python is changed. That
needs to be discussed on python-dev first, and I hope that the new build
infrastructure will *not* use the PCbuild8 directory (but perhaps move
rename that directory to PCbuild instead, or just upgrade the project
files in PCbuild).
In addition, I hope that VS 2005 will *not* be the next default compiler
for Python, but that VS 2008 will be the new compiler.
if you like to help and spend some time on getting VS2008 support into
Python 2.6 and 3.0 I'm willing to assist you. You can download the Beta
2 of the VS C++ 2008 Express Edition from http://msdn2.microsoft.com/en-us/express/future/bb421473.aspx
IMHO the order of things to do is:
Get Python 2.6 and all dependencies to compile with VS2008 (PCbuild9
directory?)
One issue that also needs discussion is the structure of the build
directory. It could temporarily be PCbuild9, but in the long run, it
should replace PCbuild. Apart from that, the issue is whether there
should be a flat structure as it is currently in PCbuild, or a nested
one as it is in PCbuild9; I think that flat is better than nested. Then
another issue is whether it should support building both AMD64 and x86
from the same source tree; I don't think that this is necessary. And so
on; this really needs to be discussed on python-dev.
So at least on my system, the assertion is triggered that the file is
not found.
The other changes look fine. Just in case it isn't clear: you can add a
config.py to your msi directory, to set things like PCBUILD and MSVCR to
the values you like.
Activity
weck commentedon Nov 15, 2007
with vs 2003, msi.py get msvcr71.dll from msm. but with vs 2005, It's
better to extract msvcr80.dll from %VCINTALLDIR%\redist\x86
\Microsoft.VC80.CRT\. In addition, it seems to extract file from
Microsoft_VC80_CRT_x86.msm need upgrade MSI to 3.1, i am not sure.
I 'PCbuild' to 'PCbuild8' in msi.py and add extract_msvcr80, that will
make msi.py work with vs 2005.
tiran commentedon Nov 15, 2007
I'm resetting the target version of all your MSVC patches to 2.6 + 3.0.
While we can't alter the compiler version of Python 2.5 I really like to
update to a new compiler for 2.6 and 3.0.
tiran commentedon Nov 15, 2007
The patch looks fine but I've a small request. Could you please use a
global var PCBUILD instead of "PCBuild" / "PCBuild8" and change the
dependencies to use either MSVCR 71 or 80 depending on the content of
the var. This way the msi module can handle both versions.
loewis commentedon Nov 15, 2007
I'm opposed to this patch. Any change to the MSI build process should
only be made when/after the default compiler for Python is changed. That
needs to be discussed on python-dev first, and I hope that the new build
infrastructure will *not* use the PCbuild8 directory (but perhaps move
rename that directory to PCbuild instead, or just upgrade the project
files in PCbuild).
In addition, I hope that VS 2005 will *not* be the next default compiler
for Python, but that VS 2008 will be the new compiler.
tiran commentedon Nov 15, 2007
Weck,
if you like to help and spend some time on getting VS2008 support into
Python 2.6 and 3.0 I'm willing to assist you. You can download the Beta
2 of the VS C++ 2008 Express Edition from
http://msdn2.microsoft.com/en-us/express/future/bb421473.aspx
IMHO the order of things to do is:
directory?)
loewis commentedon Nov 15, 2007
One issue that also needs discussion is the structure of the build
directory. It could temporarily be PCbuild9, but in the long run, it
should replace PCbuild. Apart from that, the issue is whether there
should be a flat structure as it is currently in PCbuild, or a nested
one as it is in PCbuild9; I think that flat is better than nested. Then
another issue is whether it should support building both AMD64 and x86
from the same source tree; I don't think that this is necessary. And so
on; this really needs to be discussed on python-dev.
tiran commentedon Nov 18, 2007
I've used parts of the patch for the MSI fix for VS 2008. I've got most
of the VS 2008 related changes done. Have a look.
loewis commentedon Nov 18, 2007
Did you test the change for VS 2003? In my MSMDir
(C:\Programme\Gemeinsame Dateien\Merge Modules), I only have the
following files
GDIPlus.msm
msmask32_X86.msm
msmask32_X86_ENU.msm
VB_Control_mschart_RTL_X86_---.msm
VB_Control_mschart_RTL_X86_ENU.msm
VC_User_ATL71_RTL_X86_---.msm
VC_User_CRT71_RTL_X86_---.msm
VC_User_MFC71_Loc_RTL_X86_---.msm
VC_User_MFC71_RTL_X86_---.msm
VC_User_STL71_RTL_X86_---.msm
VJSharpRedist_x86.msm
WMIUTILS_RTL_X86_---.msm
WMI_DECOUPLED_PROVIDER_RTL_X86_---.msm
So at least on my system, the assertion is triggered that the file is
not found.
The other changes look fine. Just in case it isn't clear: you can add a
config.py to your msi directory, to set things like PCBUILD and MSVCR to
the values you like.
tiran commentedon Nov 18, 2007
Martin v. Löwis wrote:
I don't have the MSM files for 7.1, just the files for 8.0 and 9.0. I
assume that the files are part of VS 2003. I don't have VS 2003 around.
I only installed VS .NET 2003 and C++ Toolkit 2003 as described at
http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit
Feel free to revert my changes to the 7.1 code.
Christian