По умолчанию в фоне у приложения убиваются сокеты — вряд ли в iSH прикрутили Network Extension (то, через что все впн клиенты работают, например), чтоб можно было подобные трюки проворачивать.
и еще один прикол: не могу попасть на сайт в локалке по IPv4, но если открывать его по mDNS имени, то заходит (вероятно, резолвится в IPv6 адрес). При этом при обращении к другому сайту на том же адресе, но порте 8096 (Jellyfin) — все хорошо. От браузера, опять же, не зависит.
По-хорошему все адреса из локалки должны полностью игнорироваться.
Проверил в Макос на сафари и фф. Как только отключаешь прокси (сделал внутри фф), сразу все работает. Помимо ют у меня добавлены домены дискорда, пара трекеров и медиум.
Conan все еще нельзя использовать как пакетный менеджер С++
мы в проекте чудесно его используем, причем и для мобильных платформ тоже. Щас как раз заканчиваем портирование на v2.
Qt официально не поддерживает conan
как и более 95% других библиотек. Но что значит «поддерживать» Конан? «Рецепты» Конана — всего лишь набор команд по сборке и установке библиотек, которые можно и ручками вызвать.
С тех пор в марте 2025 у Qt вышел релиз 6.9.0, но его до сих пор не смогли вмержить в conan-center-index
При этом есть два закрытых, но не вмерженных пулл реквеста с обновлением версии qt (первый, второй).
если все-таки почитать ПРы, то там не «не смогли вмержить», а:
на CI не собирается из-за старого тулчейна
автор тупо закрыл ПРы, потому что их не вмержили достаточно быстро / не адаптировали CI — как будто обиделся
ничего не мешает вновь их открыть и вступить в контакт с мейнтейнерами CCI, чтоб мерж все-таки произошел.
При этом digia делала некоторые попытки самостоятельно оседлать conan движение и выпустила свой conan репозиторий, но похоже там все заглохло
да, где-то они писали (в блоге вроде), что забили из-за очень малого спроса. А жаль.
Отсутствуют релизы. Основной поддерживаемый conan репозиторий - это conan-center-index. В нем отсутствуют релизы как таковые. Это значит, что если вы жестко не укажете версию зависимостей (включая хеш суммы бинарных пакетов), то вы рискуете в один из моментов просто потерять собираемость ваших зависимостей.
не особо понял с чего собираемость должна пропасть. Если рецепт насколько изменится, что потребует внесения каких-то правок (например, указания новых опций) в свой скрипт?
Вообще, рекомендуется хранить свои бинарные пакеты на своем сервере (артифактори ну либо в виде архива). Также можно иметь клон CCI нужных рецептов. Можно даже исходники библиотек кэшировать.
Conan нельзя использовать в качестве системного пакетного менеджера
его никто и не позиционирует так.
Если ваш пакет явно не инклудит <cstdint>, но при этом использует типы оттуда, то он просто не соберется у конечного пользователя.
так он и без Конана не соберется. Это проблема кода программы/библиотеки, а не пакета Конана. Конечно, в отдельных случаях можно накатить свой патч на подобную проблемную библиотеку либо при возможности решить это через разные точки кастомизации Конана, но это уже как обходные пути.
Conan подходит для фиксации текущей версии сборки, но не для непрерывного выпуска обновлений. Исходя из описанных выше проблем, каждое обновление версий зависимостей может превратиться в “приключение на 20 минут” для каждой из платформ
чаще всего с Конаном это никак не связано: ручное обновление зависимости точно так же может вызвать ошибку сборки.
Сложно добиться аппрува. Первый мой пулл реквест в conan-center-index прошел достаточно быстро, но второй висит уже неделю без движения на стадии “получить аппрув для сборки”.
Да, и это частая претензия к CCI (можно в issues найти). Причина ясна: мейнтейнеров крайне мало, а ПРов — много, ресурсы CI также ограничены. У меня ПРы и месяцами висят, но это никак не мешает использовать свои форки с правками при сборке зависимостей.
При использовании addObserver(forName: игнорирование возвращаемого значения является ошибкой: хоть захват weak self и спасает от утечки, но уведомление все равно будет доставляться нам снова и снова в замыкание. А возвращает этот метод как раз некий observer (сам NotificationCenter хранит на него сильную ссылку внутри себя), который и надо подавать в метод removeObserver(). Ну либо использовать старый добрый метод добавления наблюдателя через обжс метод, а не замыкание, тогда отписка от наблюдения будет произведена автоматически при смерти объекта - явно писать removeObserver(self) в deinit/dealloc уже давно не нужно.
не заметил никаких проблем с установкой нужной deployment target, в чем у вас там была загвоздка — непонятно...
не сразу нашел документацию на построение из исходников, но в ней оказалась полезная ссылка на .bazelrc файл. В нем достаточно легко найти способ указания деплоймент таргета для Макос (--macos_minimum_os=11.0), тогда можно даже чисто наугад предположить как должна называться настройка для iOS.
Построим свежий релиз (2.17) командой, указанной в статье, получим ожидаемый результат (использовал хкод 15.4):
Хотел также проверить на релизе 2.12, который указан в статье, но там при сборке что-то пошло не так, видимо проблема с питоном 3.12: ModuleNotFoundError: No module named 'distutils'.
В этом и была проблема, что мы не смогли его использовать (дефолтный iOS SDK). Какие бы мы опции не пробовали, в итоге всегда собиралось под дефолтный iOS 16.0 SDK. Перепробовали все, что можно, перед тем, как ставить xCode, у которого дефолт именно iOS 14.0
Вообще, звучит как баг библиотеки. Но уже стало интересно что ж там за магия такая, попробую сам её собрать и сообщу о результате.
По идее XCode 14 (а в теории и 15, 16) должны без проблем собирать, используя iOS SDK 14.0. Самой ошибки не было – фреймворк просто гордо работал только от 16 iOS, что не соответствовало нашим требованиям. Эта проблема съела львиную долю времени и мы были рады найти хоть какой-то хак, а суть проблемы до сих пор остается непонятной.
Причем у нас есть уверенность, что правильное решение элементарное, на уровне указания флага или лишней настройки, но найти его не удалось. Будем рады, если кто-нибудь прольет свет на эту ситуацию.
Теперь проблема начинает проясняться. Хкод 14.х поставляется с 16.х сдк, а если при сборке не указывать никакой деплоймент таргет, то будет использоваться версия сдк, вот и получается, что у вас минимальная версия проставлялась 16.х. Неужели вы не пробовали задать нужный вам деплоймент таргет и даже не смотрели в итоговые флаги компиляции?
Особо разницы никакой, но нам было проще сделать CMakeLists.txt
и добавили еще одну сущность :) плюс дополнительная нагрузка на того, кто будет это сопровождать в будущем.
---
Кстати, можно поступить немного хитрее. Описать свою обертку в виде подспека, и уже использовать его как единый источник правды для построения бинарника. Тогда получится, что есть некая шаблонная часть подспека, которая будет единой как для "исходного" подспека (из которого будем строить бинарь), так и для "бинарного" (который будет распространяться для интеграции), ну и каждый из подспеков добавляет что-то свое. "Исходный" подспек может использоваться для демо-проекта, который будет выступать как песочница / проверка библиотеки на "здравый смысл". А при выполнении pod install для демо-проекта у нас как раз и появится хкод проект для построения фреймворка.
(конечно, от шаблонов можно отказаться и просто не забывать вносить правки в оба файла одновременно)
Ошибку, связанную с нелегальностью такой сборки, 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-бит).
прошу прощения, я слепой :)
Просто оставлю это тут https://habr.com/ru/articles/911260/
Кстати в том же конане тоже есть бинари, но лишь для "стандартной" конфигурации опций конфигурации.
Потому что других бинарей 5.15 для опенсорса и нет, в официальном установщике тоже лишь 5.15.2
По умолчанию в фоне у приложения убиваются сокеты — вряд ли в iSH прикрутили Network Extension (то, через что все впн клиенты работают, например), чтоб можно было подобные трюки проворачивать.
очень интересно как поставить питон на неджейлнутый девайс ;)
и еще один прикол: не могу попасть на сайт в локалке по IPv4, но если открывать его по mDNS имени, то заходит (вероятно, резолвится в IPv6 адрес). При этом при обращении к другому сайту на том же адресе, но порте 8096 (Jellyfin) — все хорошо. От браузера, опять же, не зависит.
По-хорошему все адреса из локалки должны полностью игнорироваться.
заметил интересную особенность: с включенным прокси перестали загружаться детали шагов в GhA, ни один не раскрывается. Пример: https://github.com/Laserlicht/vcmi/actions/runs/15363242333/job/43232920944
Проверил в Макос на сафари и фф. Как только отключаешь прокси (сделал внутри фф), сразу все работает. Помимо ют у меня добавлены домены дискорда, пара трекеров и медиум.
у меня на Макос Сонома тоже отлично работает. Но проблем с загрузкой проца не наблюдаю.
вывод статистики там можно отключить через параметр
-qОбидно за Конан.
мы в проекте чудесно его используем, причем и для мобильных платформ тоже. Щас как раз заканчиваем портирование на v2.
как и более 95% других библиотек. Но что значит «поддерживать» Конан? «Рецепты» Конана — всего лишь набор команд по сборке и установке библиотек, которые можно и ручками вызвать.
если все-таки почитать ПРы, то там не «не смогли вмержить», а:
на CI не собирается из-за старого тулчейна
автор тупо закрыл ПРы, потому что их не вмержили достаточно быстро / не адаптировали CI — как будто обиделся
ничего не мешает вновь их открыть и вступить в контакт с мейнтейнерами CCI, чтоб мерж все-таки произошел.
да, где-то они писали (в блоге вроде), что забили из-за очень малого спроса. А жаль.
не особо понял с чего собираемость должна пропасть. Если рецепт насколько изменится, что потребует внесения каких-то правок (например, указания новых опций) в свой скрипт?
Вообще, рекомендуется хранить свои бинарные пакеты на своем сервере (артифактори ну либо в виде архива). Также можно иметь клон CCI нужных рецептов. Можно даже исходники библиотек кэшировать.
его никто и не позиционирует так.
так он и без Конана не соберется. Это проблема кода программы/библиотеки, а не пакета Конана. Конечно, в отдельных случаях можно накатить свой патч на подобную проблемную библиотеку либо при возможности решить это через разные точки кастомизации Конана, но это уже как обходные пути.
чаще всего с Конаном это никак не связано: ручное обновление зависимости точно так же может вызвать ошибку сборки.
Да, и это частая претензия к CCI (можно в issues найти). Причина ясна: мейнтейнеров крайне мало, а ПРов — много, ресурсы CI также ограничены. У меня ПРы и месяцами висят, но это никак не мешает использовать свои форки с правками при сборке зависимостей.
Креатор можно скачать ещё с гитхаба без регистрации и
смсвпн: https://github.com/qt-creator/qt-creator/releasesПри использовании addObserver(forName: игнорирование возвращаемого значения является ошибкой: хоть захват weak self и спасает от утечки, но уведомление все равно будет доставляться нам снова и снова в замыкание. А возвращает этот метод как раз некий observer (сам NotificationCenter хранит на него сильную ссылку внутри себя), который и надо подавать в метод removeObserver(). Ну либо использовать старый добрый метод добавления наблюдателя через обжс метод, а не замыкание, тогда отписка от наблюдения будет произведена автоматически при смерти объекта - явно писать removeObserver(self) в deinit/dealloc уже давно не нужно.
не заметил никаких проблем с установкой нужной deployment target, в чем у вас там была загвоздка — непонятно...
не сразу нашел документацию на построение из исходников, но в ней оказалась полезная ссылка на .bazelrc файл. В нем достаточно легко найти способ указания деплоймент таргета для Макос (
--macos_minimum_os=11.0), тогда можно даже чисто наугад предположить как должна называться настройка для iOS.Построим свежий релиз (2.17) командой, указанной в статье, получим ожидаемый результат (использовал хкод 15.4):
А теперь передадим флажок
--ios_minimum_os 15.0:Хотел также проверить на релизе 2.12, который указан в статье, но там при сборке что-то пошло не так, видимо проблема с питоном 3.12: ModuleNotFoundError: No module named 'distutils'.
Вообще, звучит как баг библиотеки. Но уже стало интересно что ж там за магия такая, попробую сам её собрать и сообщу о результате.
Теперь проблема начинает проясняться. Хкод 14.х поставляется с 16.х сдк, а если при сборке не указывать никакой деплоймент таргет, то будет использоваться версия сдк, вот и получается, что у вас минимальная версия проставлялась 16.х. Неужели вы не пробовали задать нужный вам деплоймент таргет и даже не смотрели в итоговые флаги компиляции?
и добавили еще одну сущность :) плюс дополнительная нагрузка на того, кто будет это сопровождать в будущем.
---
Кстати, можно поступить немного хитрее. Описать свою обертку в виде подспека, и уже использовать его как единый источник правды для построения бинарника. Тогда получится, что есть некая шаблонная часть подспека, которая будет единой как для "исходного" подспека (из которого будем строить бинарь), так и для "бинарного" (который будет распространяться для интеграции), ну и каждый из подспеков добавляет что-то свое. "Исходный" подспек может использоваться для демо-проекта, который будет выступать как песочница / проверка библиотеки на "здравый смысл". А при выполнении pod install для демо-проекта у нас как раз и появится хкод проект для построения фреймворка.
(конечно, от шаблонов можно отказаться и просто не забывать вносить правки в оба файла одновременно)
я бы уточнил, что проблема будет только при заливке в аппсторконнект, при этом на макос приложения это ограничение не распространяется. А если распространять просто ipa файл всем желающим, то этого ограничения тоже нет.
очень странно... И как раз было бы интересно посмотреть на ошибку и изучить ее причину, а не использовать подобные «хаки» (понятно, что тогда могло не быть времени разбираться, но уж сколько времени прошло с тех пор). Да и почему хкод 12, а не 13? А что насчет современного хкода 15 (и даже беты 16)?
а зачем это делать, если в итоге мы все равно через
vtoolзадаем нужную версию?И кстати получить версию сдк и платформы также можно через
vtool(вместо otool).но ради чего, если никто не мешает использовать библиотеки с меньшим деплоймент таргетом?..
а зачем нам смаке, если в итоге все равно используется хкод генератор? Что мешало просто создать хкод проект?
тут стоит указать, что предполагается, что мы находимся в папке сборки, которая лежит внутри корня исходников. Но предпочтительнее:
так не делать и держать папку сборки снаружи папки исходников
явно указывать каталоги исходников и сборки. В данном случае мы бы написали
cmake -S .. -B ., хотя более традиционной формой является конфигурация из папки исходников:cmake -S . -B buildдо этого мы все собирали в терминале, а теперь внезапно надо открывать иде :) Собрать хкод проект можно через xcodebuild или fastlane.
не очень понятно зачем явно указывать
CLANG_CXX_LIBRARY, если она уже сто лет как установлена в libc++ по умолчанию.подождите, а разве
MyFrameworkне зависит отTensorflowLiteFramework, выступая оберткой над ней? В таком случае зависимость отTensorflowLiteFrameworkдолжна быть указана в подспекеMyFramework. Если же основной фреймворк также напрямую зависит отTensorflowLiteFramework(вызывает что-то оттуда в обход обертки), тогда да, следует указать эту зависимость в основном фреймворке.Я понимаю, что оно работает и так, но лучше все делать аккуратно :)
P.S. Вопросики к колонке Архитектура для симуляторов у картинки под спойлером: какие-то там очень странные значения написаны. Они ж должны практически совпадать со значениями в строке Макбук за исключением того, что для симуляторов iOS < 11 использовалась i386 (интел 32-бит).
(но лишь для арм маков)
не х2, а х1.5
Речь шла, естественно, о современных машинах :) РРС можно на 10.6 запустить, но делать этого сейчас, конечно же, никто не будет
но честно скажем: портирован пока что далеко не до конца, например скрипты не поддерживаются
Родной версии нет. Но есть CrossOver, wine и т.п. Ну или виртуальные машины.