2015-06-22 5 views
5

Ich baue ein plattformunabhängiges Cython-Projekt, bei dem ich Compiler-Argumente basierend auf dem verwendeten Compiler übergeben möchte. Ich kann den Compiler basierend auf der Plattform schätzen oder annehmen, dass es derselbe Compiler ist, der für Python verwendet wird, aber es ist nicht garantiert, dass er übereinstimmt. Normalerweise injiziere ich die Methode cmdclass arg zu setuptool setup und umgehe die Befehle install oder build_ext, um den internen Status zu überprüfen. Aber in diesem Fall muss ich die Erweiterungsmodule cythonisieren, bevor ich die Wrapper erreiche.Wie kann der Compiler identifiziert werden, bevor Cython-Erweiterungen definiert werden?

Gibt es eine Möglichkeit, den Compiler in setup.py vor dem Cything der Erweiterungsmodule zu ermitteln?

+0

können Sie den Compiler als Argument nicht an setup.py übergeben: 'python setup.py build --compiler = mingw32'? – denfromufa

+0

können Sie auch cmake verwenden, um Cython-Code plattformübergreifend zu kompilieren: https://github.com/thewtex/cython-cmake-example – denfromufa

+0

@denfromufa Sie können '--compiler = mingw32' übergeben, aber andere Empfänger der Das Repository weiß nicht unbedingt, worauf das Compiler-Argument zu setzen ist oder ob es sich um eine Abhängigkeit von einem anderen Repo handelt. Und 'pip install' wird definitiv kein solches Argument für setuptools erzeugen. Ich könnte das Argument lesen, wenn ich selbst nur "python setup.py install" benutze - das stimmt. – Pyrce

Antwort

2

Nachdem ich in den Cython-Foren gepostet und nach verwandten Problemen in Distutils gesucht habe, habe ich this post gefunden, die zeigen, wie man die Compiler-Argumente in die build_ext-Zuweisung verschiebt. Wenn ich anschließend alle Compiler-Argumente aus der Erweiterungsklasse entferne, kann ich sie jetzt wie erwartet in der Befehlsklasse zuordnen. Ich kann auch install und egg_info Befehlsklassen erhalten, um meine neue Version von build_ext auch aufzurufen.

BUILD_ARGS = defaultdict(lambda: ['-O3', '-g0']) 
for compiler, args in [ 
     ('msvc', ['/EHsc', '/DHUNSPELL_STATIC']), 
     ('gcc', ['-O3', '-g0'])]: 
    BUILD_ARGS[compiler] = args 

class build_ext_compiler_check(build_ext): 
    def build_extensions(self): 
     compiler = self.compiler.compiler_type 
     args = BUILD_ARGS[compiler] 
     for ext in self.extensions: 
      ext.extra_compile_args = args 
     build_ext.build_extensions(self) 

... 
setup(
    ... 
    cmdclass={ 'build_ext': build_ext_compiler_check }) 
+0

Das gleiche scheint mit '' 'aus setuptools.command.build_ext import build_ext''' zu funktionieren (der vorherige Link hatte Störungen, die Leute heute als veraltet oder vollständig in setuptools integriert betrachten, wenn ich mich nicht irre, korrigiere mich, wenn ich bin falsch) –

+0

Das ist richtig. Der Import von setsetool funktioniert genau gleich und sollte anstelle des Importes von distutils verwendet werden. obwohl ich nicht weiß, wann disttitils tatsächlich verschwinden wird oder soll zum Sonnenuntergang, wie ich es nur als ein Wunsch auf Pythonbrettern erwähnt habe und nicht eine Voraussetzung. – Pyrce

Verwandte Themen