Russian Qt Forum

Отписываемся, если что-то другое, добавлю.

Для проекта с использованием Qt - qmake.
без Qt - cmake

Поскольку это Qt-форум, проголосовал за qmake

Смутно представляю что за "система сборки" ???  Наверное имеется ввиду "создать новый проект" (из имеющихся исходников). Тогда CMake (на OSX), но на Вындоуз редко, там обычно все идет с MSVC проектами/солюшнами (этот choice популярен, его не мешает добавить)

Автоматизация сборки (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8)

После перехода на Qbs забыл qmake как страшный сон.

А как нынче с поддержкой qbs в креаторе?
Раньше добавить/удалить/переименовать файл без правки файла проекта было невозможно (

Вполне хорошо, каких-то больших жалоб у меня не возникает. Понятно, что есть куда стремиться и всегда хочется чего-то получше, но в целом поддержка нормальная.


Файлы по одному я в проект не добавляю, они оформлены в группах. Обычно файлы находятся под управлением системы контроля версий и удалять/переименовывать/добавлять их лучше согласно её способам. В креаторе потом нужно лишь сделать "Build/Reparse Qbs".

Кстати, с последним обновлением в qtcreator улучшена поддержка cmake. Теперь имеются профили сборки с задаваемыми переменными.

То есть, все по-прежнему - только ручками. ((
Создание класса из визарда для qbs-проекта уж больно муторное, 3-х этапное: 1. собственно, создание; 2. правка файла проекта; 3. репарс проекта.
Ненене, нафик...

А вот по поводу системы контроля версий... ну вот ваще не понял -/

а что нет в qmake, что есть в qbs или cmake?
qbs не знаю, cmake не знаю - мне хватает qmake )
каких удобств я лишаюсь используя qmake ?

если на винде надо не просто собирать, а активно чето писать в немаленьком проекте, то студия; в остальных случаях qmake. (до qbs пока руки не доходят)

>>каких удобств я лишаюсь используя qmake ?
Если у тебя в исходниках есть одноимённые файлы, например:
diagram/utils.{cpp|h}
metrology/utils.{cpp|h}

То ты лишаешься возможности собрать проект. Т.к. qmake все объектники валит в один каталог, т.е. получится так:
сначала скомпилится diagram/utils.{cpp|h} и получится utils.o
затем скомпилится metrology/utils.{cpp|h} и получится utils.o, который перезапишет предыдущий.

в остальном мне больше нравится qmake, по сравнению с cmake и qbs

Всё это делаю через интерфейс qtcreator (qmake). Контроль версий (git) не спотыкается. При удалении файла спрашивает удалить ли из контроля, при добавлении сразу же делает git add, после переименовывания, в окне создания коммита я вижу, что у файла поменялся путь.

Визардами не пользуюсь, мне от них никакого толка нет, они не знают структуру файлов моих проектов. Создаю файлы ручками, напряжным это не считаю. Файл проекта при этом не меняется. Остаётся только в креаторе один пункт меню ткнуть.


Я CMake тоже не знаю, так что за него не скажу. В Qbs намного проще описывать сложные проекты, состоящие из множества модулей (библиотек, приложений). Зависимости одних модулей от других разруливаются намного лучше, и не зависят от расположения модуля в файловой системе, на чём спотыкается qmake. Удобнее описывать структуру проекта, можно написать "модуль" который потом применяется как шаблон для продукта. Можно заводить переменные в файлах проекта, и в дочерних проектах доступны переменные супер-проекта, в qmake с этим тоже затык. Скорость сборки больших проектов выше. Репарсинг проектных файлов больших проектов намного выше. Это навскидку. А так в Qbs намного больше полезных плюшек, чем в qmake :).

На ОSX соответственно Xcode. Шо за "сборки/разборки" - хз. Само слово гнусное: "собирать" - а не надо было разбрасывать.

rly?
Сборка (программирование) (https://ru.wikipedia.org/wiki/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5))

ПлюсЫ, Qt, кроссплатформенность... не? мысль улавливаете?
Нужен универсальный способ собирать исходники на разных платформах.
Потому вопрос о предпочтении qmake|cmake|qbs..., а не MSVC|Xcode...

Такими возможностями креатора не пользовался, мне в винде намного удобней это в TortoiseGit делать :). Сейчас попробовал в проекте Qbs в креаторе файлы переименовывать/удалять, с git корректно работает. Выдаётся предупреждение, что не может файл переименовать/удалить в проектном qbs-файле, но там они поштучно и не описаны :). Правда приходится руками жать "Build/Reparse Qbs", это похоже на косяк, могло бы и автоматом это делаться, раз файл изменился.

да, так не получится, но это мелочи

за счет чего ?
ведь сборка проекта это сборка каждого файла и в конце линковка - что тут qbs может ускорить ?

qmake генерит кучу Makefil'ов по которым выполняется сборка. Qbs строит дерево сборки целиком и сам вызывает компиляторы/линкеры и прочее. Лучше отслеживает изменения в структуре проектов и пересобирает необходимый минимум. Немного здесь описано: Introducing qbs (http://blog.qt.io/blog/2012/02/15/introducing-qbs/) Fast incremental builds. У меня на большом проекте проверка изменений в qmake могла занимать и минуту, даже если изменений никаких и не было. И так при каждой сборке. На Qbs это же занимало 0 секунд. Ну ладно, 0.5 секунды :).

очень странно:
1. qmake генерит один Makefile и ничего не вызывает при сборке, это делает make
2. make пересобирает только измененные фалы, при это qmake вообще не участвует
3. pro файл меняется редко, потому как его qmake парсит меня не напрягает
4. при каждой сборке qmake не участвует, если pro файл не менялся

может мы о разном говорим ?

хотя если проект состоит из "200 libraries, 50 classes per library, 30 lib-internal includes per file and 10 lib-external includes per file" то его наверно я замечу разницу
но такие проекты я еще не создавал )

Пока это имеет смысл только для десктопных приложений. Но для дебаженья андройда и embedded linux (ЕМНИП), QBS к сожалению не торт, приходится богомерзкий qmake юзать.  :-\

А по всем другим вещам QBS впереди всех перечисленных по удобству, скорости, разруливанию зависимостей и прочее (тут уже все ViTech разъяснил)! :)

У меня, к примеру, QBS занимается также и деплоем (вызывает windeployqt), созданием инсталляторов (также и deb пакетов), "подписыванием" бинарей приложений/библиотек, добавлением в них RC секций и прочих няшек-плюшек.. И все это в одном проекте!  Попробуйте-ка на qmake/CMake это замутить - получите вигвам, и будете долго плеваться!

1. qmake генерит один Makefile  для каждого модуля (библиотеки, приложения). В проекте их могут быть десятки.
2. make пересобирает только измененные файлы, но для этого должен зайти в каждый модуль и проверить изменился ли он. Это и отмечают в Introducing qbs (http://blog.qt.io/blog/2012/02/15/introducing-qbs/) Fast incremental builds.
3. В проектах со сложной структурой и зависимостями между модулями на qmake надо знатно извратиться, чтобы эти зависимости разрешить. Поэтому парсинг qmake может изрядно напрягать.
4. На большом проекте я уже вникать не стал, кто там участвует: qmake, make или кто-то ещё :). Тормоза по сравнению с Qbs просто громадные.

Я говорю о проекте в котором, допустим, штук 20 библиотек и 10 приложений :).

Кроме qtcreator кто-нибудь ещё поддерживает qbs?

Пока нет, но это не проблема. :)

Ни чего себе мелочи! Нет возможности собрать проект - нет конечного продукта. Это не мелочи.

Как из этой ситуации выходить?
- Перепахивать чужие модули? Какая при этом версия модуля получится?
- Писать (копипастить) модуль заново и потом постоянно синхронизировать его с оригинальным?

Если ты не одноразовые игрухи под мобилки клепаешь, а пользуешся выверенными модулями, то это огромная проблема.

- qmake генерит один Makefile
- запускается Make, видит инструкцию в MakeFile - "сделай с помощью qmake Makefile.Debug" и "сделай с помощью qmake Makefile.Release"
- qmake генерит один Makefile.Debug
- qmake генерит один Makefile.Release

При стандартном потходе, когда make вызывается без параметров debug или release, дальше картина выглядит так:
Make заходит в Makefile.Debug и выполняет его инструкции (проверяя изменившиеся файлы), затем Make заходит Makefile.Release и делает тоже самое над теми же файлами (в том числе проверку на изменения).
Т.е. по меньшей мере в 2 раза удлиняя процесс сборки.
Поэтому я инклюдю в свой профайл собственный "стандартный! конфиг и использую явные команды make debug и make release

Если имеются субпроекты то триад make-файлов бутдет на каждый субпроект.

если используешь QSS воткнутый внутрь ресурсов, то никогда не проверяется изменение QSS, единственный способ - прибить соответствующий объектник.

так что у qmake есть весьма серьёзные проблемы,
но QBS пока напоминает студенческие эксперементы, такие же как и в проекте Оберон (Никлауса Вирта и Юрга Гукнехта).
Т.е. завтра внесут изменения и твой проект станет не понятен QBS-у (много раз сталкивался на чужих проектах, посему приходится держать несколько креаторов (старые не удалять).
Плюс ещё и ты должен вместо прикладной задачи заниматься слежением за блогом разработчиков QBS-а, что бы знать, что поменяли и чего тебя ждёт.

CMake - слишком много телодвижений требуется, чтобы создать проект. Его поддержка в креаторе - ущербная. У меня креатор ещё не разу неасилил создать CMake проект, который бы завёлся сразу - напоминает совавтопром - Доработай напильником, потом поедеш.

Про какие телодвижения разговор? Я уже лет 8 использую CMake и проблем не знаю.

(немного не по теме сборки) да, кстати. в креаторе удобно только коннекты прописывать да реализации методов создавать (последнее студия умеет, в отличие от Xcode), но пытаться использовать std-контейнеры с шаблонным параметром сложнее int уже крайне трудно из-за периодического пропадания автодополнения. С Objc кодом та же ситуация, только там автодополнение не работает в принципе.

а и студия, и Xcode собирают (строят :) ) проект ощутимо быстрее, как по мне. под виндой разве что jom еще кое-как выручает.

Я после CLion не могу QtCreator'ом пользоваться.

Лучше пользоваться тем, чем умеешь).

Сейчас в моем проекте ~100 модулей, между которыми имеются зависимости. Используя структуру проектов, которую я здесь уже описывал http://www.prog.org.ru/index.php?topic=30171.msg222516#msg222516, легко с помощью qmake компоную различные комплексы из любого сочетания таких модулей.

Следование единой технологии позволяет существенно упростить процесс ведения проектов с использованием любого инструмента.
На большом количестве модулей qmake несущественно притормаживает. Пробы qbs показали существенно лучшую производительность, но законченную технологию еще пока не разработал.

а как в неё вошли ?
обычно имя файла (модуля) это имя класса, получается 2 класса с одинаковым именем, но делающие разные вещи ?

Я часто в такое вхожу :). Например, могут быть классы с одинаковым именем и похожим поведением в разных пространствах имён. Файлы с одинаковым именем могут находится в разных каталогах и система сборки должна уметь корректно с этим работать. Равно как и IDE их адекватно отображать. С недавнего времени в креаторе в окне "Open Documents" к файлам с одинаковыми именами начали приделывать куски путей, чтобы их различать. Но не всё еще безоблачно: Switching header/source doesn't always find correct file (https://bugreports.qt.io/browse/QTCREATORBUG-13953). А когда система сборки не может с этим совладать - это полный капец.

Посмотри на приведённый мною пример, там видно что речь идёт не о классах, а об утилитах (специфичных для конкретного модуля) - это первый момент.
Второй момент может быть и с классами. Для одного проекта писался некий модуль. Спустя время был заимствован в другой проект, в котором уже есть одноимённый файл.
Другими словами в реальном проекте подобное совпадение имён - обычное дело, но для qmake не съедобно, только из-за глупой попытки валить все объектники в отдельный каталог.

Не, не улавливаю. Это для подключения каких-то либов исходники которых мне видеть не нужно. Ну нашел инструкцию, "собрал" по ней и подключил полученные либы к проекту. Так бывает, но 2-3 раза в год. А обычно рабочий проект - его постоянно надо активно править и отлаживать - без IDE все равно не обойтись, так чего мудрить?

Ну какжеж?.. Солюшин от мелкомягких полезен только для Windows. Я вот о чем...

В общем-то ничто особо не мешает для одного набора исходников написать проектные файлы для разных систем сборки, разных версий одной системы сборки, проектных файлов IDE и т.п. Они друг другу мешать не будут. Другое дело - поддерживать их все в актуальном состоянии :).

Вполне съедобно, если добавить


Добавлено в Qt5.

исходники qtcreator не содержат повторяющихся имен файлов
мне бы проект с одинаковыми именами не понравился, я бы переделал
но для меня это мелочи )

деплой средствами qbs меня наверно не привлекает, bash интереснее будет
вот впилят qbs дефолтно в креатор, тогда и погляжу

Что значит дефолтно? Щас в креатор и qmake, и cmake, и qbs, и autotools впилены, как бы, равноправно )

Неверно.
fileutils.cpp[h] есть в coreplugin и в utils
правда в разных подпроектах, это, кстати, qmake вполне переваривает )

да, я неверно подсчитал
из 2558 файлов 58 имеют повторы (из тех исходников что у меня завалялись)
возможно не все в проекте, не проверял

Намедни узнал про CMake support in Visual Studio 2017 (https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/). Мож пригодится кому.

Перевёл некоторые проектики свои на Qbs. Быстрая сборка, приятный синтаксис, но как уже говорилось, картину портят разные недоделки. Например, решил добавить для gcc флаги для оптимизации под конкретный процессор, типа -mfpath=sse -march=pentium4 и т.д.
Обнаружилось следующее: как только добавляем в cpp.cxxFlags флаг -march=xxx, перестает собираться:
...а в qbs.architecture можно указать лишь в общих чертах: "x86", "x86_64", "arm".
Гуглю, висит баг QBS-1018 (https://bugreports.qt.io/browse/QBS-1018) и в комментах рекомендуют для этого использовать недокументированное свойство cpp.machineType, значение которого при использовании GCC будет передаваться параметру -march

Javascript
Properties {
    condition: qbs.toolchain.contains("gcc")
    cpp.machineType: "pentium4"
    cpp.cxxFlags: ["-mfpmath=sse"]
}
 

Так работает, но баг открытый с сентября прошлого года и всё по прежнему, в документации про machineType ничего нету и т.д.  :-\