andrew_121, вы собирали при помощи qmake проекты зависящие не только от Qt и приличного размера? До cmake ей (системе сборки) еще далеко. Чего не хватает - отслеживание зависимостей, более гибких configure etc.

Ручное добавление файлов это не так страшно на самом деле. 

Кстати, один плюс cmake - любая IDE позволяющая работать с Makefile автоматически будет поддерживать cmake, для qmake нужен дополнительный бубен, чтобы обновлять Makefile при обновлении .pro файла.

имхо: для меня Qt Creator совершенно не удобен.

приличного размера - да.
зависящие от стороних - нет. либо сторонние собираю сам, ручками так сказать.

Добавлено через 2 минуты и 50 секунд

так было раньше. сейчас make проверяет .pro файл, и если он изменился, то запускает qmake.

kemiisto, извините я не телепат.

Кстати говоря тролли сами осознали ненужность qmake, в будущем, будет cmake, кажется.

точно. уже сейчас версию с джиториуса нужно собирать cmake/

Откуда такая информация? Просмотрел все бранчи ни одного упоминания о CMakeLists.txt не нашел.


И снова, откуда вы это берете? Все статьи, которые я читал на http://labs.trolltech.com/blogs/ про cmake говорят лишь о том, что тролли общались с KitWare по поводу некоторых возможностей, которых им не хватает. Однако окончательного решения по этому вопросу еще небыло принято, т.к. вторым вариантом является создание новой системы сборки основанного, скорее всего, на ECMAScript (он же JavaScriptCore и QtScript).

И уж тем более там было сказано о том, что qmake останется для обратной совместимости с существующими проектами.

Это сообщение отредактировал(а) SABROG - 6.1.2010, 15:56

да вряд-ли они будут переписывать все с нуля, скорее всего они просто напишут(или уже написали) тулзу, которая перегонит все .prj файлы в CMakeLists.txt

щас найду.

Ну движок у них есть (ecmascript), основные методы выдерут из того же qmake. К тому же им нравится идея о создании системы сборки в качестве библиотеки, которую можно будет подключить напрямую к QtCreator'у, а не через консоль. Это позволит QtCreator'у парсить скрипты сборки на раз два (вернее это будет делать уже сама библиотека, может плагин, кто знает) и генерить удобный интерфейс для изменения проекта. Думаю, что скрипты будут чем-то напоминать систему сборки waf, которая на питоне. Хотя кто знает.

M Любитель

Тема выделена отсюда - http://forum.vingrad.ru/forum/topic-286047.html

Выскажу уж своё мнение 

Во-первых, я бы выделил три юз-кейса, исходя из которых я привык оценивать билд системы:
1. Сборка проекта девелопером. Быстро, интегрируемо с ИДЕ (не только мифическими ИДЕ - в первую очередь с реальными), обязательна максимальная инкрементность сборки. Вполне нормально, если нужна дополнительная настройка энвайронмента.
2. Сборка проекта из сорсов юзером. Юз-кейс, конечно, больше всего актуален в мире никсов. Здесь требуется максимальная автоматизация процесса, здесь звучит популярная фраза о "гибком configure", здесь может понадобится замысловатая кастом-логика.
3. Классический CI. Энвайронмент настраивается, но единожды (прописать нужные утилиты в PATH, подсунуть куда надо нужные либы и т. д.). Билд-система в этом своём образе должна уметь брать информацию из сорс-контроля (да, основная работа ложится на CI-сервер, но там номер ревизии проставить в конфиг - тоже полезно), прогонять тесты, пекеджить деплоймент-версии проекта. Должна работать на 100% автоматически.

По 1-му пункту (если говорить об интеграции с реальными ИДЕ) сливают все. Makefile-based проект - это отстой по определению. Т. е. разработчики билд-системы должны сделать нормальную поддержку проектов в VS и эклипсе (с криэйтором всё само собой - поэтому эт я даже не заикаюсь).

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

Наконец-таки, насчёт CMake. Действительно, как я понимаю (да - Qt я уже давно не занимаюсь, но интересуюсь), выбор пока не сделан (http://labs.trolltech.com/blogs/2009/10/14/to-make-or-not-to-make-qmake-and-beyond-redux/). Вариант с JS-based скриптингом и декларативном описание тарджетов мне нравится 

Хотя XML-based build script нравится больше (наверно, привык). С возможностью написания кастом-тасков, загружаемых через механизм плагинов Qt 

второй пункт в топку, сборка из исходников пользователем is so 1994  

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

Не понял   


Неее.. Эт я знаю. Добавили мы в ИДЕ новый файл, теперь дополнительно должны отредактировать конфиг для билд-системы. Это не тру-вей. Редактировать конфиг вручную - тоже не айс. Исключение - кастомные операции. Т. е. надо не генерить файл проекта, а сделать поддержку нового типа проектов для основных ИДЕ (эклипс, VS + XCode, который я забыл в прошлый раз). Это было бы лучшим решением.

Вообщем, я за QAnt + редактор для него в ИДЕ 

одну строчку добавить в CMakeLists.txt
я это делаю из IDE, затем запускаю сборку и у меня автоматически вызывается cmake и обновляется solution



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

Добавлено через 2 минуты и 47 секунд
вообще, мне сложно представить единую систему сборки поддерживаемую всеми IDE, поэтому лучше уж так, как это делает  cmake, чем вообще никак  

Ну не знаю... В этой же теме вон выступали за "нормальный конфигуре" 


Ды я понимаю.. Суть в том, что все операции надо дублировать :( Это плохо.


Ммм.. Ну в мире явы же вроде как-то все уживаются? Хотя я особо этот вопрос не копал 

Добавлено через 1 минуту и 8 секунд
Ну и макросы цмейка мне лично не нравятся. Но это дело вкуса, конечно.

>Makefile-based проект - это отстой по определению.

Эээ... Вы где такое глупое определение прочитали? Можно поподробнее? Давно уже веду все свои проекты на Makefile и не знаю бед. А несколько IDE, что я видел, умели работать с кастомными мэйкфайлами.

>одну строчку добавить в CMakeLists.txt

Вроде бы cmake умеет работать не с файлами, а с директоряими исходников.

>сборка из исходников пользователем is so 1994

Гентушники переглянулись, возмущенно зашумели, зыфыркали и неодобрительно закачали головами.