LINUX.ORG.RU

Чем CMake лучше qmake?


0

3

Предположим мы хотим написать приложение средних размеров на Qt c использованием IDE QtCreator. Надо определиться с системой автоматизации сборки. Что лучше выбрать CMake или qmake?

Это же совершенно разные вещи: qmake — для поделок на кутях, cmake — для всего.

Eddy_Em ☆☆☆☆☆
()

Не знаю на счёт qmake, но CTest (включая Valgrind), CPack - очень удобные штуки.

backbone ★★★★★
()

Тем, что не прибит гвоздями к Qt?

хотим написать приложение средних размеров на Qt

Так и надо было спрашивать. Тогда используйте qmake, конечно.

buddhist ★★★★★
()
Ответ на: комментарий от ZuBB

сейчас новьій тренд - QBS

В чат пожаловали некроманты использующие альфа софт

bhfq ★★★★★
()
Ответ на: комментарий от Deleted

я не знаю. чесно говоря работа всех подсистем Х'ов для меня темньій лес.. :(

Ну так разве работа Compose не зависит от настройки метода ввода Х?

а как проверить?

ZuBB ★★★★★
()
Ответ на: комментарий от Eddy_Em

уже перестало.

postman_, Eddy_Em если поможете разобратся - с меня пиво при встрече

итак результаты по латинице и комбинации compose + . + s (рез-т: ):

  • работает в фф (xul)
  • работает в geany (gtk)
  • не работает в vbox(qt)
  • не работает в xterm,urxvt

итак результаты по кирилице и комбинации compose + . + і (рез-т: ı):

  • один раз заработало в фф (xul)
  • один раз заработало в geany (gtk)
  • не работало в в xterm,urxvt
  • не успел потестить в vbox(qt)

есть xubunta 12.04 с сессией fluxbox`а.

еще есть такое

include "/usr/share/X11/locale/en_US.UTF-8"                                     
                                                                                
<Multi_key> <Ukrainian_ie> <Ukrainian_ie> : "э" U044d                           
<Multi_key> <Ukrainian_i> <Ukrainian_i> : "ы" U044b                             
 
в .XCompose но оно кажись не работает

и еще

vv@vv-Latitude-E5520 ~ $ grep setxkbmap !$
grep setxkbmap .fluxbox/startup
setxkbmap -layout 'us,ua' -variant ',winkeys,winkeys' -option 'grp:alt_shift_toggle,compose:ralt' &
vv@vv-Latitude-E5520 ~ $ 
ZuBB ★★★★★
()
Ответ на: комментарий от ZuBB

/usr/share/X11/locale/en_US.UTF-8/Compose

Ну и сам можешь чего угодно понапридумывать в ~/.XCompose

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)

CMake, конечно.

unfo ★★★★★
()
Ответ на: комментарий от Eddy_Em

локаль в юникод выставить

vv@vv-Latitude-E5520 ~ $ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
vv@vv-Latitude-E5520 ~ $ 

общесистемную

но зачем?

ZuBB ★★★★★
()
Ответ на: комментарий от ZuBB

ХЗ, посмотри мою тему, в которой я жаловался на нерабочий compose.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от buddhist

Не офтопь, мы тут о высшем работе compose рассуждаем!

Eddy_Em ☆☆☆☆☆
()

QMake принципиально не является системой инкрементальной сборки и содержит массу проблем, которые никогда не будут решены ибо противоречат основной её задумке. Единственное назначение qmake: сборка самой Qt и его примеров. Плюс через qmake можно получить значения аргументов с которыми данная версия Qt была собрана. Точка.

Начинайте изучать CMake. Оно того стоит.

Dendy ★★★★★
()
Ответ на: комментарий от Dendy

У ТСа было сказано:

Предположим мы хотим написать приложение средних размеров на Qt c использованием IDE QtCreator.

Вы вообще в курсе, какая разница в интеграции криэйтора с qmake и cmake? К cmake даже файлы автоматически не добавляются. К тому же синтаксис qmake намного проще, хотя cpack/ctest у него конечно нет.

quiet_readonly ★★★★
()
Ответ на: комментарий от Eddy_Em

Ъ-кодер волен пойти и стать ментейнером CMake в QtCreator, там как раз место пустует. Или взять и допомогтi киевлянину gribozavr с интеграцией clang в vim; когда он научится читать настройки cmake - флаги, include paths, пользовательские макросы - и передавать их clang, дабы тот всё корректно разбирал и подсвечивал, вот тогда и поговорим.

В QtCreator для qmake передача флагов, include paths и макросов движку анализа кода работает корректно почти всегда, осталась парочка недобитых багов.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

парочка недобитых багов

Это непереносимость(между разными ОС или дистрибутивами) конфигов смейка от кутекриатора,где половина путей абсолютная,и вообще страх и ужас с путями?

По теме:
Я предпочитаю вообще классический make без лишних костылей,симейк это костыль,бесполезный.

anonymous
()
Ответ на: комментарий от anonymous

Ваши навыки диагонального чтение поражают. Для анализа кода движку IDE (равно как и редактора вроде vim/emacs) нужно знать: пути поиска заголовков, флаги компиляции, предопределённые макросы. QtCreator выдирает их из qmake так же, как это делает сам qmake при сборке, если не считать парочки не добитых багов.

Конфигами смейка от кутекриатора я вообще не пользуюсь и не в курсе что как.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

Ещё раз повторюсь: QMake принципиально не является инкрементальной системой сборки. Это значит, что использовать её внутри любой IDE противоречит самой идеологии. Тот факт, что разработчики QtCreator вопреки здравой логике таки всунули QMake в IDE только вводит людей в заблуждение. Пусть сначала добавили бы в QMake инкрементальность, потом был бы разговор, но они сами признались, что развитие QMake зашло в тупик и Qt/QtCreator нуждаются в нормальной системе сборки.

Вообще сама идея вместе со своей библиотекой классов писать ещё и систему сборки попахивает сами знаете чем. Библиотека должна предоставлять утилиты, учавствующие в тулчейне, такие как moc, uic, rcc, lupdate, etc и это абсолютно нормально. Если и предоставлять систему сборки, то только для сборки библиотеки с нуля, к примеру, для автоматизации создания пакетов. Чем qmake с успехом и занимается, на чём его конечная цель и заканчивается.

Я с успехом пользуют связкой QtCreator + Makefile Project, причём для проектов самой разной направленности: CMake, C/C++, Android, Java, Python. Если у автора проект небольшой, то будет проще прописать лишние пару строчек в *.files, *.includes и *.config для правильного нахождения путей и разворачивания макросов.

Dendy ★★★★★
()
Ответ на: комментарий от Deleted

большое спасибо, работает!

если бы здесь была хаброкарма — нажал бы Вам 9к плюсов!

ZuBB ★★★★★
()
Ответ на: комментарий от Eddy_Em

А я так и думал, что говнокути только быдлокодеры и используют…

Ох-хо-хо...Эдди в своём неизменном стиле. Постоянство признак качества? :)

Что же тебе Qt так поперёк яиц встал? В детстве что ли тебя им запугали?

И как будто нельзя использовать связку qmake+cmake? Кто запретил?

DeVliegendeHollander ★★
()

Говорю как неосилятор qmake: CMake как-то проще осваивается, особенно с:

cmake --help-command
cmake --help-variable
cmake --help-module

К тому же - CMake более кросс-платформенный (в плане умения генерации проектных файлов).

Советую начинать проект с СMake, так как в сети больше примеров реализации тех или иных вещей на последнем.

KennyMinigun ★★★★★
()
Ответ на: комментарий от Dendy

QMake принципиально не является системой инкрементальной сборки и содержит массу проблем, которые никогда не будут решены ибо противоречат основной её задумке.

Зато синтаксис хотя бы отчасти декларативен

annulen ★★★★★
()

Для qt ни чем. Для остального лучше что позволяет выжечь напалмом qt в радиусе километра

vertexua ★★★★★
()
Ответ на: комментарий от DeVliegendeHollander

Что же тебе Qt так поперёк яиц встал? В детстве что ли тебя им запугали?

Вроде того ☺

И как будто нельзя использовать связку qmake+cmake?

Можно, но лучше обойтись последним.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

CMakeList заполнять ручками может позволить себе крупный проект, где всегда найдётся знаток cmake, либо проект, в котором один из основателей знает cmake и твёрдо верит в него. А если его можно заполнять только ручками - целая категория людей разочаруется и убежит хорошо если на qmake, а то и на visual studio. И никак назад не заманите.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

Дык, я про быдлокодеров не говорю. Неужто нормальный программист будет всем этим вашим говном, вроде эклипсов/kdevelop'ов и прочей параши пользоваться?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Дык, я про быдлокодеров не говорю. Неужто нормальный программист будет всем этим вашим говном, вроде эклипсов/kdevelop'ов и прочей параши пользоваться?

Разрыв шаблона? Ну дело знамое, лечится даже - эвтаназией.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

А если его можно заполнять только ручками - целая категория людей разочаруется и убежит хорошо если на qmake, а то и на visual studio. И никак назад не заманите.

Даже в разработке на Java (где порог вхождения куда ниже чем в C++, а народу куда больше) давно уже переходят на maven, в какой-то степени аналог CMake, т.к. позволяет собирать проект независимо от IDE и управлять внешними зависимостями. Только быдлокодеры жестко привязаны к своей единственной IDE, так что пусть бегут, кому они нужны?

kamre ★★★
()
Ответ на: комментарий от Eddy_Em

Неужто нормальный программист будет всем этим вашим говном, вроде эклипсов/kdevelop'ов и прочей параши пользоваться?

Сборка и запуск тестов не должны зависеть от IDE, а использовать уместно все что позволяет повысить эффективность разработки. Одни нормальные программисты используют vim/emacs/gdb, другие нормальные ведут разработку в eclipse/kdevelop/qtcreator. Зачем кого-то ограничивать в выборе средств?

kamre ★★★
()
Ответ на: комментарий от Eddy_Em

Кстати, насчёт идентичности «Qt-программирование == быдлокодерство» (заявлено тобою): у тебя есть серьёзные основания для такого заявления? Сколько приложений на Qt ты написал? (ладно, даже включая хелловорлды") Хотя бы десяток наберётся?

Можно, но лучше обойтись последним.

А вот при использовании Qt qmake делает много полезной работы. Без Qt, разумеется, cmake вполне достаточно. Хотя cmake я не так давно начал плотно осваивать, и по нему у меня мало есть, что сказать.

DeVliegendeHollander ★★
()
Ответ на: комментарий от Eddy_Em

Неужто нормальный программист будет всем этим вашим говном, вроде эклипсов/kdevelop'ов и прочей параши пользоваться?

Нормальный программист отличается от ненормального не фанатской приверженностью||ненавистью к конкретным IDE, а умением использования всех полезных фичей и удобств для наиболее эффективной разработки. Проще говоря, нормальность программиста выбором IDE не определяется. Ну во всяком случае, это далеко не главный и не определяющий критерий.

DeVliegendeHollander ★★
()
Ответ на: комментарий от kamre

Все так ловко меняют тему и уходят от вопроса ТСа. Для программ на Qt требуются дополнительные действия, которые qmake выполняет автоматом. В QtCreator добавление и переименование файлов автоматически отражается в файлах кумейка. Сам по себе qmake достаточно хорошо поддаётся анализу и QtCreator из него извлекает параметры, нужные для анализа кода. Так что

Только быдлокодеры жестко привязаны к своей единственной IDE, так что пусть бегут, кому они нужны?

Не быдлокодеры, а вполне здравые люди, которые код пишут, а не dsl на лиспе создают или офигенные скрипты сборки для каждого хеллоуворлда ваяют. Поумерьте пыл и элитизм.

quiet_readonly ★★★★
()
Ответ на: комментарий от Eddy_Em

Да я знаю. :) Просто после длинной паузы заглянул на ЛОР, а тут ещё хуже, чем было, сплошная мертвечина и скучина. Вот я и цепляюсь — хучь какой «оживляж». :) Плюс знаю, как ты не любишь кеды и Qt. :) Провокации, в общем.

DeVliegendeHollander ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.