2016-04-07 2 views
2

Я пишу расширение Python в C++. Я скомпилировать его, определив список составляющих исходных файлов в моем setup.py файл, например так:Distutils: компиляция исходного файла Objective-C++ как часть расширения C++

extensions = { 
    'im': [ 
     "im/src/buffer.cpp", 
     "im/src/detail.cpp", 
     "im/src/gil.cpp", 
     "im/src/halideimage.cpp", 
     "im/src/hybrid.cpp", 
     "im/src/hybridimage.cpp", 
     "im/src/options.cpp", 
     "im/src/pybuffer.cpp", 
     "im/src/pycapsule.cpp", 
     "im/src/structcode.cpp", 
     "im/src/typecode.cpp", 
     "im/src/module.cpp" 
    ], 
} 

... они используются для определения экземпляра setuptools.Extension, который в конечном счете передается функции setup(). Это все работало просто отлично на протяжении всего проекта, до сих пор, когда я попытался добавить конкретную платформу немного:

preview_source = (sys.platform == 'darwin') and 'im/src/plat/preview_mac.mm' or \ 
        (sys.platform == 'linux') and 'im/src/plat/preview_linux.cpp' or \ 
        (sys.platform == 'win32') and 'im/src/plat/preview_windows.cpp' or \ 
               'im/src/plat/preview.cpp' 

extensions = { 
    'im': [ 
     "im/src/buffer.cpp", 
     "im/src/detail.cpp", 
     "im/src/gil.cpp", 
     "im/src/halideimage.cpp", 
     "im/src/hybrid.cpp", 
     "im/src/hybridimage.cpp", 
     "im/src/options.cpp", 
     preview_source, 
     "im/src/pybuffer.cpp", 
     "im/src/pycapsule.cpp", 
     "im/src/structcode.cpp", 
     "im/src/typecode.cpp", 
     "im/src/module.cpp" 
    ], 
} 

... добавив этот новые бит выбирает правильный файл для компиляции - но он не компилировать на все на Mac OS X. по-видимому distutils/setuptools не признает «.mm» расширение в качестве исходного файла:

unknown file type '.mm'

error: unknown file type '.mm'

Я не эксперт, когда речь идет о distutils в nd setuptools Конфигурация на платформе - какой простой способ условно добавить этот один исходный файл в список исходных файлов на Mac?

ответ

2

Я столкнулся с тем же вопросом, вы когда-нибудь находили какое-то решение?

Похоже, что «.mm» не поддерживается в моей версии distutils, но «.m» есть. Поэтому я отделил части файла .mm и C++ в файле .cpp и создаю небольшой заголовок C для доступа к файлу .m из этого .cpp.

+0

То, что я закончил, это все переименование файлов .mm' в файлы '.m', а затем добавление' -x object-C++' в компилятор args - решение, которое не является переносимым (я думаю, '- x' - это вещь, связанная только с глагью) и не подлежит (учитывая, что файлы по существу теперь неправильно названы). Ваше решение кажется более чистым, но в равной степени неприхотливым для долгосрочного ... Я все еще ищу реального решения проблемы. – fish2000

+1

Спасибо, что вернулись ко мне. В чем проблема с использованием .m-файлов, похоже, что все работает нормально. Кажется, это долгая выдающаяся ошибка, которую distutils не обрабатывает .mm. Я нашел сообщение об ошибке + патч с 2001 года (16 лет назад !!!) об этом: https://mail.python.org/pipermail/distutils-sig/2001-December/002695.html –

+0

Одна из проблем с необходимостью использования '.m' заключается в том, что в тех случаях, когда реализация объединена на цель Objective-C++ и как таковая не может быть легко разбита на единицы перевода по языку, как вы могли это сделать - вы в конечном итоге с файлом типа «ублюдок-из-Winterfell», который не играет хорошо, например Xcode или cmake и т. Д. На самом деле это не так, как вы отмечаете, конец света - это та проблема, которая вызывает воспаление OCD моего программиста; в то время как суффикс файла - это только одна точка отсчета, он остается самым надежным метаданным, который у вас есть для файла, и так далее. Но все же: 16-летняя ошибка, что? – fish2000

Смежные вопросы