Я пытаюсь использовать distutils для компиляции модуля cython с использованием версии python Enthought Canopy; однако ясно, что есть путаница между gcc и clang. Distutils пытается скомпилировать модуль, используя gcc и параметр clang -arch x86_64. Проблема в том, что у меня установлен gcc с macports, так что gcc это не просто ссылка на clang. Я могу заставить модуль скомпилироваться с помощью CC='clang' ./setup.py build_ext, но это кажется немного хакерским с точки зрения распространения модуля. Есть ли что-то, что я могу добавить в setup.py, чтобы сделать его более надежным при такой настройке? Я думаю что-то вроде использования clang, если -arch находится в флагах компилятора, но я не могу найти, где именно distutils получает флаги компилятора или как сказать ему использовать определенный компилятор.
компиляция модулей cython, когда gcc находится в PATH в OSX
Ответы (1)
Distutils пытается скомпилировать модуль, используя gcc и параметр clang -arch x86_64.
Это не вариант лязга; это было в gcc за много лет до появления clang.
Проблема в том, что у меня установлен gcc с macports, так что gcc это не просто ссылка на clang.
gcc никогда не является просто ссылкой на clang, если вы действительно не сделали что-то странное на своем Mac. В частности, если вы установили инструменты командной строки Xcode, необходимые для включения MacPorts, у вас будет /usr/bin/gcc, который является ссылкой на gcc-4.2 или llvm-gcc-4.2 (или gcc-4.0 или старше). Скоро Apple прекратит поддержку llvm-gcc, и gcc вообще не будет.**
Я могу заставить модуль скомпилироваться с помощью CC='clang' ./setup.py build_ext, но это кажется немного хакерским с точки зрения распространения модуля.
Очевидно, что модуль собирается с gcc, что означает Apple /usr/bin/gcc.
Надеяться, что gcc будет каким-либо конкретным компилятором, почти всегда плохая идея, как объясняется в документации MacPorts.
Однако в данном случае Python имеет смысл это сделать. Python запоминает компилятор, использованный для его сборки, и те же настройки компилятора и т. д., поэтому он может быть уверен, что distutils создаст модули, которые он действительно может использовать. Итак, если он был собран с помощью /usr/bin/gcc, с -arch x86_64, он попытается использовать его для сборки модулей. Вы можете запустить инструмент python-config (каждая из ваших установок Python будет иметь свою собственную, поэтому убедитесь, что вы запускаете правильную), чтобы точно увидеть, что он хочет.
Вы почти всегда можете избежать неприятностей, заменив Apple clang на Apple gcc-4.2. Но заменить какой-то другой случайный компилятор, который даже не поддерживает те же параметры? Это не сработает.
Если вы хотите создавать модули Python с помощью MacPorts, вы почти наверняка хотите создавать сам Python с помощью MacPorts, а не использовать какой-либо предварительно скомпилированный двоичный установщик. Кроме того, вы, вероятно, захотите использовать порты для любых модулей Python, в которых они есть, вместо того, чтобы создавать их вручную, потому что многие из них требуют обходных путей для работы с MacPorts.
С другой стороны, если вы планируете создавать программное обеспечение, отличное от MacPorts, — модули Python или что-то другое — вам действительно лучше не ставить MacPorts gcc на первое место в PATH. Почти каждый файл configure/setup.py/etc. когда-либо написанный обнаружит, что вы работаете на Mac, ожидая, что gcc будет Apple gcc, и передаст флаги -arch и так далее. (На самом деле вы заметите, что даже многие порты явно требуют apple-gcc-4.2, llvm-gcc-4.2 или clang, потому что даже команда MacPorts не смогла заставить их работать с другим компилятором. Вы уверены, что хотите пытаться?)
* … и это будет ссылка, скажем, на ../llvm-gcc-4.2/bin/llvm-gcc-4.2, которая сама будет ссылкой или оболочкой-заглушкой вокруг i686-apple-darwin11-llvm-gcc-4.2… но это не важно.
** Или, по крайней мере, это было верно время от времени в бета-версиях Xcode 5.0.
