Как стать автором
Обновить

Комментарии 15

Мне кажется, не хватает введения в cmake
Не в статье в смысле, а вообще на Хабре.
Возможно, но писать общие вводные статьи, пересказывая хелп, как-то не слишком хочется. Хотя действительно на Хабре нету статей про cmake. Да и не очень ясно в какой их блог пихать. Не в Qt же.
Честно говоря, мануал cmake довольно сложен для понимания, особенно тяжело с примерами: «для чего используется тут это?» и «а как сделать это?».
Из текста так и не понял, можно ли таким образом создать нормальный установочный пакет (с выбором компонентов, путей размещения файлов и ярлыков и т.д.) и есть ли поддержка .deb/.rpm или это только для того, чтобы объединить в один пакет исполняемые файлы и библиотеки.
Нет, это для бандлов «всё в одном». Для rpm/deb зависимости, как правило, лучше не пихать в пакет, а предоставить как зависимости пакета. И для этого есть CPack.
Вполне можно нормальный nsis таким образом сделать или pkg. Ну а для создания rpm/deb лучше написать spec или debian.
Я на своём огромном проекте использую cmake и должен сказать, что не особо рад (но так исторически сложилось)… cmake это только генератор скриптов и проектов которые в свою очередь должны использоваться для сборки. Короче CMake — это надстройка над ругими билд системами и в этом его и сильная и слабая сторона. Возможно для маленьких проектов это супер, но для огромных кросскомпиляционных проектов со многими сложными зависимостями — упрётесь в ограничения встроенного языка cmake и необоснованными ребилдами с нуля всего проекта после внесения незначительных (на первый взгляд) изменений. Я вот лично думаю передвинуть проект в сторону scons.
Читал я про scons и честно сказать, на вид он ещё хуже. Хоть cmake в некоторых случаях и не сахар, но он лучше, чем autotools и, если судить по синтаксису, то покрасивше scons'а. Хотя меня лично напрягает нечувствительность к регистру в некоторых местах cmake'а и чувствительность в других. В итоге стиль быстро теряется. Но увы, пока ничего лучшего не придумали.
Оптимистичная статья. Давно ищу повод перейти с make'а на cmake в Qt-проектах. Если упаковка бандла под маком действительно упрощается, то стоит попробовать. Скажите, а как будет выглядеть упаковка в бандл и релокация фреймворков Qt?
всю работу делает otool. Можно через негобандл с примером посмотреть
Сейчас так и работаю — сборка мейком, упаковка бандла самописным скриптом с релокацией otool'ом. В лучшем случае случае можно организовать вызов упаковочного скрипта на post-build шаге. Но в идеале (все мы перфекционисты, верно?) хотелось бы получить управление сборкой и упаковкой в одном флаконе. Это стремление заставляет смотреть по сторонам.
У Нас в кутиме тоже скрипт из цмака пускается но я надеюсь его заменить на метод из статьи. Он в винде работает без изменений
Скажите, а как будет выглядеть упаковка в бандл и релокация фреймворков Qt?

Упаковка в бандл на маке есть и без cmake — macdeployqt
Да, есть такая буква. Правда на практике пришлось перейти к ручному контролю за упаковкой. Видимо сказывается сложность проекта (собственные плагины и прочие прелести).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.