Comments 4
Где же вы были 5 лет назад, когда я очень хотел нагуглить такую статью))
5 лет назад код на C++ без танцев с бубном собирался просто включением соответствующих файлов на C++ в ObjC-проект с изменением их расширения на .mm. Или даже и переименовывать не надо было, не помню уже -- старый стал. Полагаю, что и сейчас этот способ работает.
Этот же совет можно использовать и для работы со Swift ниже версии 5.9.
Ох, уж эти зуммеры, раз и навсегда похоронившие ObjC ^.^
Ошибку, связанную с нелегальностью такой сборки, XCode выдаст только при попытки опубликовать сборку такого приложения.
я бы уточнил, что проблема будет только при заливке в аппсторконнект, при этом на макос приложения это ограничение не распространяется. А если распространять просто ipa файл всем желающим, то этого ограничения тоже нет.
Собрать модуль на XCode 14 под минимальный таргет 14 не удалось, поэтому первым шагом потребовалось установить XCode 12
очень странно... И как раз было бы интересно посмотреть на ошибку и изучить ее причину, а не использовать подобные «хаки» (понятно, что тогда могло не быть времени разбираться, но уж сколько времени прошло с тех пор). Да и почему хкод 12, а не 13? А что насчет современного хкода 15 (и даже беты 16)?
После копирования SDK поменяем свойство
MinimumSDKVersion
а зачем это делать, если в итоге мы все равно через vtool задаем нужную версию?
И кстати получить версию сдк и платформы также можно через vtool (вместо otool).
Так мы создали TensorflowLiteFramework.framework, который можем использовать в проекте с минимальным таргетом iOS 14.0.
но ради чего, если никто не мешает использовать библиотеки с меньшим деплоймент таргетом?..
Теперь сконфигурируем сборку с помощью Cmake
а зачем нам смаке, если в итоге все равно используется хкод генератор? Что мешало просто создать хкод проект?
cmake ..
тут стоит указать, что предполагается, что мы находимся в папке сборки, которая лежит внутри корня исходников. Но предпочтительнее:
так не делать и держать папку сборки снаружи папки исходников
явно указывать каталоги исходников и сборки. В данном случае мы бы написали
cmake -S .. -B ., хотя более традиционной формой является конфигурация из папки исходников:cmake -S . -B build
Запускаем в XCode проект MyFramework.xcodeproj и внутри XCode собираем фреймворк под целевую платформу
до этого мы все собирали в терминале, а теперь внезапно надо открывать иде :) Собрать хкод проект можно через xcodebuild или fastlane.
TensorflowLiteFramework.podspec
не очень понятно зачем явно указывать CLANG_CXX_LIBRARY , если она уже сто лет как установлена в libc++ по умолчанию.
s.dependency 'TensorflowLiteFramework'
подождите, а разве MyFramework не зависит от TensorflowLiteFramework , выступая оберткой над ней? В таком случае зависимость от TensorflowLiteFramework должна быть указана в подспеке MyFramework . Если же основной фреймворк также напрямую зависит от TensorflowLiteFramework (вызывает что-то оттуда в обход обертки), тогда да, следует указать эту зависимость в основном фреймворке.
Я понимаю, что оно работает и так, но лучше все делать аккуратно :)
P.S. Вопросики к колонке Архитектура для симуляторов у картинки под спойлером: какие-то там очень странные значения написаны. Они ж должны практически совпадать со значениями в строке Макбук за исключением того, что для симуляторов iOS < 11 использовалась i386 (интел 32-бит).
Работа с кодом на C++ в Swift