Construindo LXML para Python 2.7 nas janelas

StackOverflow https://stackoverflow.com/questions/3047542

Pergunta

Estou tentando criar LXML para o Python 2.7 na máquina Windows de 64 bits. Não consegui encontrar a versão LXML Egg para Python 2.7. Então, estou compilando -o de fontes. Estou seguindo instruções neste site

http://lxml.de/build.html

em seção de vinculação estática. Estou recebendo erro

C:\Documents and Settings\Administrator\Desktop\lxmlpackage\lxml-2.2.6\lxml-2.2.
6>python setup.py bdist_wininst --static
Building lxml version 2.2.6.
NOTE: Trying to build without Cython, pre-generated 'src/lxml/lxml.etree.c' need
s to be available.
ERROR: 'xslt-config' is not recognized as an internal or external command,
operable program or batch file.

** make sure the development packages of libxml2 and libxslt are installed **

Using build configuration of libxslt
Building against libxml2/libxslt in one of the following directories:
  ..\libxml2-2.7.6--win32--w2k--x64\lib
  ..\libxslt-1.1.26--win32--w2k--x64--0002\lib
  ..\zlib-1.2.4--win32--w2k--x64
  ..\iconv-1.9.1--win32--w2k--x64-0001\lib
running bdist_wininst
running build
running build_py
running build_ext
building 'lxml.etree' extension
error: Unable to find vcvarsall.bat

Alguém pode me ajudar com isso? Eu tentei definir o caminho para ter o Microsoft Visual Studio .. Eu posso executar vcvarsall.bat a partir da linha de comando .. mas o python está tendo problemas

Foi útil?

Solução

Aposto que você não está usando o VS 2008 para isso :)

Há def find_vcvarsall (versão): função (adivinhe, ele procura vcvarsall.bat) em distutils com o seguinte comentário

A princípio, tenta encontrar o produto do VS 2008 no registro. Se isso falhar, ele voltará ao vs90Comntools Env var.

Se você não estiver usando o VS 2008, não possui a chave do registro nem a variável de ambiente adequada e é por isso que os distutils não conseguem encontrar o arquivo vcvarsall.bat. Isso faz não Verifique se o arquivo BAT é acessível através da variável do ambiente do caminho.

A solução é definir a variável VS90Comntools para apontar para o diretório de ferramentas do Visual Studio.

Dito isto, dê uma olhada em 11.4. distutils.msvccompiler - Microsoft Compiler seção nos documentos de Python, que afirma

Normalmente, os módulos de extensão precisam ser compilados com o mesmo compilador que foi usado para compilar o Python.

Martin v. Loewis no e -mail intitulado Baixe o Visual Studio Express 2008 agora na lista de discussão da lista python, afirma o mesmo

Python 2.6, 2.7 e 3.1 são todos construídos com esse lançamento (ou seja, 2008). Devido a outra longa tradição, os módulos de extensão Python devem ser construídos com a mesma versão do compilador (mais especificamente, versão do CRT) como o próprio Python. Portanto, para criar módulos de extensão para qualquer um desses lançamentos, você precisa ter uma cópia do VS 2008 ou VS 2008 Express.

À luz das declarações acima deve Use o VS 2008 se você deseja construir LXML para Python 2.7, embora o Configuração do VS90Comntools cuide de encontrar o arquivo vcvarsall.bat a solução.

Dito isto :) As pessoas tentam usar o CRT mais antigo com o mais novo compilador:
Posso usar o compilador C ++ do Visual Studio 2010 com a biblioteca de tempo de execução C ++ do Visual Studio 2008?
Como aplicar o compilador C ++ para usar a versão CRT específica?
Vs 2008 - link contra o tempo de execução mais antigo

Gostaria de agradecer a Kev Dwyer (por apontar a importância da versão do VS que é usada) e Stefan Behnel (por me apontar para os distutils como um local que lida com a configuração do compilador) no tópico Problema de criação LXML sob Windows - Erro: Incapaz de encontrar vcvarsall.bat na lista de discussão LXML. Eu também gostaria de agradecer Agroholm Do Freenode #Distutils IRC Channel para confirmação de que o DistUtils contém código que procura o arquivo vcvarsall.bat.

Outras dicas

Depois de seguir a solução recomendada:

  1. baixando VcForpython27.msi da Microsoft,
  2. Instalando (Win7, Python (x, y) 2.7.9 32bit),
  3. Inserindo / atualizando a variável do ambiente Vs90comntools para o valor do diretório de instalação (C: Arquivos de Programas (x86) Common Files Microsoft Visual C ++ para Python 9.0)

Meu problema ainda existia (quero construir uma extensão Python em c).

Eu tive que fazer os dois tweaks inacreditavelmente sujos, antes que tudo agora esteja realmente funcionando:

  1. modificar "msvc9compiler.py" dentro "C: python27 lib distutils", função find_vcvarsall, agora aponto para "Visual C ++ para Python" em vez de "VC".
  2. Copie o fundador de diretórios em "C: Arquivos de Programas (x86) Files Common Microsoft Visual C ++ para Python 9.0 " para "C: Arquivos de Programas (x86) Common Files Microsoft Visual C ++ para Python " (ou seja, um DIR nível para cima).

Não sei dizer quem estava fazendo algo errado aqui - provavelmente eu.

EDITAR. Os diretórios em movimento funcionam por causa da questão descrita em Este bug distutils.

Mesmo que o vs90comntools esteja definido, o msvc9compiler não consegue encontrar vcvarsall.bat porque está instalado em %installdir%/vcvarsall.bat e não %installdir%/VC/vcvarsall.bat

A solução alternativa descrita está usando o prompt de comando visual c ++:

  1. Digite MSVC para prompt de comando python

  2. Definir distutils_use_sdk = 1

  3. Definir mssdk = 1

  4. python.exe setup.py ...

Jorj McKie estava quase correto: na verdade instalando VcForpython27.msi Não é suficiente, e sim, há um problema nos distutils que impedem que ele encontre find_vcvarsall. De fato, a questão não está diretamente nos distutils, mas na maneira como o vcForpython27.msi foi embalado e onde vcvarsall.bat é colocado (o layout das pastas é diferente do vs2008 SDK).

Enquanto isso, uma solução alternativa simples, isso é corrigido talvez no Python 2.7.11: use o setuptools em vez de distutils.

Outra solução alternativa manual se você estiver preso aos distutils:

1) Enter MSVC for Python command prompt
2) SET DISTUTILS_USE_SDK=1
3) SET MSSdk=1
4) you can then build your C extensions: python.exe setup.py ...

Relatório de bug e solução alternativa por Gregory Szorc:http://bugs.python.org/issue23246

Mais informações e uma solução alternativa para usar %% Cython Magic dentro do ipython: https://github.com/cython/cython/wiki/cythonextensiononwindows

https://github.com/develersrl/gccwinbinários

Eu tive problemas semelhantes. Isso funcionou instantaneamente sem nada além de usar um assistente de instalação e definir uma preferência.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top