2015-06-22 14 views
5

Sto costruendo un progetto cython indipendente dalla piattaforma in cui voglio passare gli argomenti del compilatore in base al compilatore utilizzato. Posso indovinare il compilatore basato sulla piattaforma o assumere che sia lo stesso compilatore usato per Python ma non è garantito che corrisponda. Normalmente inserisco l'argomento cmdclass nel metodo di setuptool e avvolgo i comandi install o build_ext per controllare lo stato interno. Ma in questo caso devo cythonizzare i moduli di estensione prima di raggiungere i wrapper.Come identificare il compilatore prima di definire le estensioni cython?

C'è un modo per determinare il compilatore all'interno di setup.py prima di criptare i moduli di estensione?

+0

non è possibile passare il compilatore come argomento a setup.py: 'python setup.py build --compiler = mingw32'? – denfromufa

+0

puoi anche usare cmake per compilare codice cython in modo cross-platform: https://github.com/thewtex/cython-cmake-example – denfromufa

+0

@denfromufa Puoi passare '--compiler = mingw32', ma altri destinatari del il repository non saprà necessariamente su cosa impostare l'argomento del compilatore o se è una dipendenza di un altro repository. E 'pip install' sicuramente non creerà un argomento simile a setuptools. Potrei leggere l'argomento se stavo usando solo 'python setup.py install '- è vero. – Pyrce

risposta

2

Dopo aver postato sui forum cython e cercato i problemi correlati in distutils, ho trovato this post che mostra come spostare gli argomenti del compilatore nell'assegnazione build_ext. Se successivamente rimuovo tutti gli argomenti del compilatore dalla classe di estensione, ora posso pigro assegnarli all'interno della classe di comando come mi aspettavo. Posso anche ottenere le classi di comando install e egg_info per chiamare anche la mia nuova versione di build_ext.

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

La stessa cosa sembra funzionare con '' 'da setuptools.command.build_ext import build_ext''' (il link precedente aveva distutils che le persone considerano deprecate o completamente integrate in setuptools oggigiorno se non sbaglio, correggimi se sono sbagliato) –

+0

Questo è corretto. L'importazione di setuptool funziona esattamente allo stesso modo e dovrebbe essere utilizzata al posto dell'importazione delle distutils; anche se non so quando le distutils effettivamente spariranno o si suppone che al tramonto, come ho visto solo menzionato come un desiderio su schede python e non un requisito. – Pyrce

Problemi correlati