Skip to content

make msi work the vs 2005(MSVC8) #45790

Closed

Description

@weck
mannequin
BPO 1449
Nosy @loewis, @tiran
Files
  • msi.patch
  • 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 = None
    closed_at = <Date 2007-11-18.20:23:38.708>
    created_at = <Date 2007-11-15.15:23:54.243>
    labels = ['build', 'expert-installation']
    title = 'make msi  work the vs 2005(MSVC8)'
    updated_at = <Date 2007-11-18.21:36:11.461>
    user = 'https://bugs.python.org/weck'

    bugs.python.org fields:

    activity = <Date 2007-11-18.21:36:11.461>
    actor = 'christian.heimes'
    assignee = 'none'
    closed = True
    closed_date = <Date 2007-11-18.20:23:38.708>
    closer = 'christian.heimes'
    components = ['Demos and Tools', 'Installation']
    creation = <Date 2007-11-15.15:23:54.243>
    creator = 'weck'
    dependencies = []
    files = ['8754']
    hgrepos = []
    issue_num = 1449
    keywords = ['patch']
    message_count = 9.0
    messages = ['57532', '57535', '57537', '57545', '57564', '57565', '57620', '57622', '57624']
    nosy_count = 3.0
    nosy_names = ['loewis', 'christian.heimes', 'weck']
    pr_nums = []
    priority = 'normal'
    resolution = 'wont fix'
    stage = None
    status = 'closed'
    superseder = None
    type = 'compile error'
    url = 'https://bugs.python.org/issue1449'
    versions = ['Python 2.6', 'Python 3.0']

    Activity

    1. weck commented on Nov 15, 2007

      weckmannequin
      MannequinAuthor

      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.

    2. added
      buildThe build process and cross-build
      on Nov 15, 2007
    3. tiran commented on Nov 15, 2007

      @tiran
      Member

      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.

    4. tiran commented on Nov 15, 2007

      @tiran
      Member

      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.

    5. loewis commented on Nov 15, 2007

      loewismannequin
      Mannequin

      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.

    6. tiran commented on Nov 15, 2007

      @tiran
      Member

      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:

      • Get Python 2.6 and all dependencies to compile with VS2008 (PCbuild9
        directory?)
      • Fork msvccompiler and fix it for VS2008
      • Fix Tools/msi
    7. loewis commented on Nov 15, 2007

      loewismannequin
      Mannequin

      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.

    8. tiran commented on Nov 18, 2007

      @tiran
      Member

      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.

    9. loewis commented on Nov 18, 2007

      loewismannequin
      Mannequin

      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.

    10. tiran commented on Nov 18, 2007

      @tiran
      Member

      Martin v. Löwis wrote:

      Martin v. Löwis added the comment:

      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.

      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

    11. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions