Если закомментировать первую строку, результат не изменится: если view == nil, то первое обращение к этому свойству приедет к загрузке view, т.е. будет вызов loadView и т.д.
"Пакетно" менять констрэинты (например, переключаться между 2 наборами) рекомендуется делать в updateConstraints, а setNeedsUpdateConstraints как раз и подсказывает системе, что надо произвести очередной layout pass (во время которого будет вызван updateConstraints) побыстрее, а не тогда, когда системе будет удобно.
К слову, на моем проекте как раз именно на дебаге build only active architecture отключено - всё дело в том, что у тестировщика может быть ноутбук на intel и больше ничего, ему нужна сборка для симулятор x86.
Как будто можно собрать по требованию, чем каждый раз впустую собирать вторую архитектуру. Но тут скорее вопрос удобства.
а как его в конане добавить, если рецепт не написан?
понятно, что никак, если не написать рецепт.
Но суть-то не в этом, а в удобстве использования рецепта. Конану все равно какая система сборки используется для библиотеки — рецепт будет выглядеть примерно одинаково (за исключением build метода, конечно), а у CPM получается, что если библиотека собирается не через смаке, то придется приложить гору усилий, чтоб его написать.
Уж не CPM виноват, что люди поддерживают проект десятки лет и не могут написать ему cmakelists.txt
какой-нить базель и мезон тоже надо на смаке переписать, получается?
это был вопрос к @iagolubev. В дебаге традиционно активирован build only active architecture, чтоб не собирать лишнего. Да и жирные бинари уже несколько лет (с появлением арм маков) как не имеет смысла собирать, ведь в них нельзя одновременно сложить слайс для девайса и для арм симулятора.
не увидел где искать Qt для CPM. В конане (и vcpkg) он есть, конечно.
Насколько я знаю современные версии Qt поддерживают cmake, получается написали рецепт для CPM
от того, что они поддерживают смаке, не значит, что они через него собираются. 6-ка собирается через него, да, а вот 5-ка — только через свой configure.
Вот глянул в issues CPM, там как раз кто-то поинтересовался как собрать FFmpeg (который на autotools). Открываю, а там жесть через ExternalProject_Add: https://github.com/cpm-cmake/CPM.cmake/issues/480
У FFmpeg миллион параметров — видимо, придется каждому их изучать, чтоб смочь собрать через CPM с нужными настройками. А теперь сравним с рецептом Конана, где параметры вынесены в область параметров. С Qt 5 аналогично.
все копируют, но никто не знает как же правильно, так что рецепты всё сложнее и сложнее, в них какие-то странные магические действия без объяснения почему
не понимаю что же мешает спросить. Коммьюнити вполне живое, мэйнтейнеры отвечают на вопросы достаточно активно.
и что же делать с библиотеками, которые собираются не через смаке? (например, FFmpeg или Qt 5) Как шарить собранные бинари с другими людьми и CI тоже не увидел в их ридми. Наверное, как очень простая система управления зависимостями — пойдет.
совершенно неочевидно как же он должен быть написан - на примере множества людей и компаний выявлено, что написание conan рецепта это один из самых сложных навыков в программировании. Люди спокойно разбираются в шаблонах, в линуксе, в ужасной документации, но написать conan рецепт не могут
надо всего лишь смотреть на уже написанные рецепты в CCI и в документацию. И еще можно вопросы задавать — как в слаке, так и прямо в репе конана.
Также развивается Common Package Specification, который как раз и должен абстрагировать информацию о «пакете» от конкретного менеджера пакетов. В смаке 4.0 уже реализовано, вот тут статья какая-то на эту тему.
Альтстор состоит из 2 компонентов: сервер (запускается на десктопе) и мобильный клиент. Именно сервер занимается переподписью и повторной заливкой на девайс. Соответственно надо хотя бы раз в 7 дней этот сервер запускать, чтоб приложение не "сгорало".
Но есть и другие решения, которые могут переподписывать прямо на девайсе: например, SideStore.
как только появится пакет, зависящий от такого перетащенного пакета, так проблемы сразу и появятся в виде дублирующихся символов.
в целом, не особо понятно какие там проблемы со сборкой. Разве что раздутие дискового пространства из-за клонирования репы (которое решается переходом на реестр).
As some build flags can be exploited for unsupported or malicious behavior, the use of unsafe flags makes the products containing this target ineligible for use by other packages.
Очень непонятно написано. То есть если использовать unsafe flags, то автоматически downstream пакеты не будут собираться?
Предположим, для юнит-тестов необходимо загрузить некий бинарный артефакт из сети. Я простого пути «в лоб» так и не нашел.
add_custom_target либо add_custom_command + cmake -P в качестве команды позволит использовать все встроенные средства смаке в своем кастомном скрипте, например тот же file(DOWNLOAD).
В CMake необходимо сначала писать conan.txt, там описывать свои зависимости и опции, а далее запускать генератор для CMake в Conan
Неудачный пример с loadViewIfNeeded
Если закомментировать первую строку, результат не изменится: если
view == nil, то первое обращение к этому свойству приедет к загрузкеview, т.е. будет вызовloadViewи т.д.Этот метод - скорее как альтернатива некрасивому
"Пакетно" менять констрэинты (например, переключаться между 2 наборами) рекомендуется делать в
updateConstraints, аsetNeedsUpdateConstraintsкак раз и подсказывает системе, что надо произвести очередной layout pass (во время которого будет вызванupdateConstraints) побыстрее, а не тогда, когда системе будет удобно.Как будто можно собрать по требованию, чем каждый раз впустую собирать вторую архитектуру. Но тут скорее вопрос удобства.
понятно, что никак, если не написать рецепт.
Но суть-то не в этом, а в удобстве использования рецепта. Конану все равно какая система сборки используется для библиотеки — рецепт будет выглядеть примерно одинаково (за исключением build метода, конечно), а у CPM получается, что если библиотека собирается не через смаке, то придется приложить гору усилий, чтоб его написать.
какой-нить базель и мезон тоже надо на смаке переписать, получается?
это был вопрос к @iagolubev. В дебаге традиционно активирован build only active architecture, чтоб не собирать лишнего. Да и жирные бинари уже несколько лет (с появлением арм маков) как не имеет смысла собирать, ведь в них нельзя одновременно сложить слайс для девайса и для арм симулятора.
не увидел где искать Qt для CPM. В конане (и vcpkg) он есть, конечно.
от того, что они поддерживают смаке, не значит, что они через него собираются. 6-ка собирается через него, да, а вот 5-ка — только через свой configure.
Вот глянул в issues CPM, там как раз кто-то поинтересовался как собрать FFmpeg (который на autotools). Открываю, а там жесть через ExternalProject_Add: https://github.com/cpm-cmake/CPM.cmake/issues/480
У FFmpeg миллион параметров — видимо, придется каждому их изучать, чтоб смочь собрать через CPM с нужными настройками. А теперь сравним с рецептом Конана, где параметры вынесены в область параметров. С Qt 5 аналогично.
не понимаю что же мешает спросить. Коммьюнити вполне живое, мэйнтейнеры отвечают на вопросы достаточно активно.
а зачем собирать жирный бинарь в дебаге?
а таймкод можно, где описаны конкретные проблемы?
и что же делать с библиотеками, которые собираются не через смаке? (например, FFmpeg или Qt 5) Как шарить собранные бинари с другими людьми и CI тоже не увидел в их ридми. Наверное, как очень простая система управления зависимостями — пойдет.
надо всего лишь смотреть на уже написанные рецепты в CCI и в документацию. И еще можно вопросы задавать — как в слаке, так и прямо в репе конана.
Также развивается Common Package Specification, который как раз и должен абстрагировать информацию о «пакете» от конкретного менеджера пакетов. В смаке 4.0 уже реализовано, вот тут статья какая-то на эту тему.
Альтстор состоит из 2 компонентов: сервер (запускается на десктопе) и мобильный клиент. Именно сервер занимается переподписью и повторной заливкой на девайс. Соответственно надо хотя бы раз в 7 дней этот сервер запускать, чтоб приложение не "сгорало".
Но есть и другие решения, которые могут переподписывать прямо на девайсе: например, SideStore.
это при условии наличия enterprise акка разработчика
если у тебя нет платного акка разработчика, то да. AltStore облегчает этот процесс.
как только появится пакет, зависящий от такого перетащенного пакета, так проблемы сразу и появятся в виде дублирующихся символов.
в целом, не особо понятно какие там проблемы со сборкой. Разве что раздутие дискового пространства из-за клонирования репы (которое решается переходом на реестр).
...и они вылетят из графа зависимостей. Нехорошо получится, если что-то зависит от них (или начнет зависеть в будущем).
Очень непонятно написано. То есть если использовать unsafe flags, то автоматически downstream пакеты не будут собираться?
Не очень понял почему
unsafeFlagsнельзя в публичных пакетах, мало ли какие мне обязательные флажки для пакета надо задать. Можно ссылку?Поды тоже так могут, там надо одну настройку в Podfile прописать:
(также можно задавать linkage для конкретной зависимости)
спасибо за статью, необычно видеть грэдл в качестве выбора системы сборки под плюсы) Но для «стандартного» проекта выглядит как перебор имхо.
Хотел спросить как интегрировать Qt в грэдл проект, а уже и плагин есть, оказывается: https://github.com/axmetishe/gradle-qt-plugin
add_custom_targetлибоadd_custom_command+cmake -Pв качестве команды позволит использовать все встроенные средства смаке в своем кастомном скрипте, например тот жеfile(DOWNLOAD).есть официальный «плагин» для смаке, который сам вызовет
conan installна этапе смаке конфигурацииэта штука только для винды и считай заброшена.
Scalar
Больше похоже на смесь свифта и тайпскрипта