Чем CMake лучше qmake?

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

troll mode: ничем. сейчас новьій тренд - QBS

новьій

Красивее так: «новьıй» (compose + . + i)

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

кто все э(ctrl+c/v)ти люди? (c)

бл@, оно работает!!! но как? в моем то не настроенном флаксе (вместо полноценного DE)..

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

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

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

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

Это — особенность firefox. Ему, кстати, на самописные правила в ~/.XCompose срать с высокой колокольни!

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

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

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

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

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

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

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                             
 

и еще

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 ~ $ 

,compose:ralt'

начинаю доганять. а где посмотреть все комбинации с compose?

Чтобы это работало в иксах, нужно общесистемную локаль в юникод выставить. Увы.

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

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

CMake, конечно.

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

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 ~ $ 

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

но зачем?

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

на кой? cmake отлично интегрируется с qt

В смысле — ту, в которой у тебя иксы запускаются.

под рутом тоже en_US.UTF-8

У меня сложилось впечатление, что ТС не особо разбирается в cmake.

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

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

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

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

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

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

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

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

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

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

есть qtest

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

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

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

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

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

А что, CMakeList ручками — не Ъ?

Ещё раз повторюсь: 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 для правильного нахождения путей и разворачивания макросов.

новьій

В Ukrainian Unicode (который уже несколько лет во всех линуксах по дефолту) «ы» набирается по AltGR + «і».

Подробнее об этой раскладке: https://plus.google.com/111300286046471278152/posts/hp8yDdaJnUf

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

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

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

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

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

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

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

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

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

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

http://industriousone.com/premake

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

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

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

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

Вроде того ☺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да ладно тебе, я же как обычно — в лужу пузыри пускаю ☺

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