To make, or not to make (вот в чём вопрос) Опции

[kwisp]

помоему это дело не то что бы вкуса.
знаю человека он к своим проектам простой makefile один раз написал и пользуется.(кстати qt он тоже собирает не плохо)
а использует остальные сборщики только когда что то чужое собирает.
тут без поллитры не разобраться.

[BRE]

знаю человека он к своим проектам простой makefile один раз написал и пользуется.(кстати qt он тоже собирает не плохо)

А если он эту программу распространять захочет? Он что делать будет?
С учетом того, что необходимые библиотеки у пользователя могут не стоять, стоять не там, где у автора и т.д.
А если пользователь еще и не разработчик, то вероятность успешной сборки проекта будет стремиться к нулю.

[kwisp]

А если он эту программу распространять захочет? Он что делать будет?
С учетом того, что необходимые библиотеки у пользователя могут не стоять, стоять не там, где у автора и т.д.
А если пользователь еще и не разработчик, то вероятность успешной сборки проекта будет стремиться к нулю.

вопросы понял.
обязательно поинтересуюсь как он свои проекты распространяет.

[igor_bogomolov]

Вот рабочий CMakeList.txt ....

Как порой удачно и своевременно возникают интересующие темы
Недавно также занялся изучением CMake, больше для саморазвития, т.к. QMake меня полностью устраивает. QMake использую не только в Qt. На самом деле QtCreator и QMake, стали для меня основной средой разработки на с++. Но не об них сейчас.

Как просто собрать Qt приложение при помощи Cmake, я разобрался. Не могу разобраться в тонкостях использования.
К примеру, если я хочу, что бы у меня была следующая структура проекта.

/bin - сюда помещался бинарник
/tmp - сюда все фойлы компиляции(*.o, moc_*, ui_* и т.д.) а так же все что создает сам CMake
CMakeLists.txt
main.cpp

Самостоятельно смог только бинарник разместить в требуемой мне директории(EXECUTABLE_OUTPUT_PATH).

Как сделать так, чтобы CMakeLists.txt оставался в корневой директории, а фалы компиляции и все то что создаёт сам CMake, перенаправить в какую-нибудь другую папочку?

З,Ы.

OBJECTS_DIT = tmp/obj
MOC_DIR = tmp/moc
RCC_DIR = tmp/rcc
UI_DIR = tmp/ui

Об этом, не могу даже и мечтать, CMake на это не способен?

[BRE]

С CMake все проще. Он все генерируемые файлы располагает в указанной папке.
Например, мы создали (или распаковали) дерево исходников в директории /src/project, а сборку мы хотим произвести в директории /src/build. Заходим в /src/build и даем команду:
cmake /src/project
make

Все файлы будут генерироваться в /src/build. Вместо очистки проекта (make distclean), мы можем просто удалить директорию /src/build со всем содержимым. Директория с исходниками вообще никак не затрагивается. Редактируем проект в /src/project, а собираем его в /src/build.

Конечно, директорию где будет происходить сборка можно назначить и /src/project/build. Вместо build можно сделать директории debug и release, в которых собирать отладочную и релизную сборку.

[SABROG]

На сколько я помню у CMAKE есть еще проблема с включением консоли (CONFIG += console). По умолчанию она выключена и чтобы её включить надо менять флаги конкретного компилятора. Т.е. уже как минимум надо писать условие типа если это компилятор gcc, msvc, bcc, icc, то чтобы включить консоль надо передать такой-то флаг, вместо универсального ключа в CONFIG.

В общем мне CMake не нравится по нескольким причинам:
- какие-то костыльные функции QT4_* (а QT3_* там есть вообще?)
- не родная система сборки. Тролли что-то поменяют или добавят и не известно, когда за ними поспеют девелоперы CMake.
- чтобы собрать Qt'шный проект нужно этот самый CMake доставить (я даже расстроился, когда тролли добавили скрипт на Python'e, чтобы собрать Qt)
- синтаксис CMake скриптов похож на язык Си (сплошные вызовы функций) и Basic одновременно из-за вечно UPPERCASE'ных их названий.

Одновременно с тем в qmake и в Makefile'ах меня немного не устраивает тот факт, что их тяжело использовать в IDE как файлы проектов из-за сложности парсинга настроек, в следствии чего все IDE используют свои собственные форматы (.sln, .vcproj, .bpr и т.д.), которые невозможно использовать с компилятором через командную строку. А многие девелоперы предоставляют только эти файлы. Хочется универсальности.

[BRE]

На сколько я помню у CMAKE есть еще проблема с включением консоли (CONFIG += console). По умолчанию она выключена и чтобы её включить надо менять флаги конкретного компилятора. Т.е. уже как минимум надо писать условие типа если это компилятор gcc, msvc, bcc, icc, то чтобы включить консоль надо передать такой-то флаг, вместо универсального ключа в CONFIG.

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

- какие-то костыльные функции QT4_* (а QT3_* там есть вообще?)

А это костыльно/не костыльно QMAKE_FRAMEWORK_BUNDLE_NAME?
Qt3 поддерживается.

- не родная система сборки. Тролли что-то поменяют или добавят и не известно, когда за ними поспеют девелоперы CMake.

Не родная, да.

- чтобы собрать Qt'шный проект нужно этот самый CMake доставить (я даже расстроился, когда тролли добавили скрипт на Python'e, чтобы собрать Qt)

Что бы собрать Qt'шный проект еще и Qt нужна.

- синтаксис CMake скриптов похож на язык Си (сплошные вызовы функций) и Basic одновременно из-за вечно UPPERCASE'ных их названий.

А у меня смешанные чувства по поводу внутреннего языка CMake, как то и просто все вроде и не просто...

Кстати с qmake тоже не все так хорошо, например: http://www.prog.org.ru/topic_8360_0.html

Одновременно с тем в qmake и в Makefile'ах меня немного не устраивает тот факт, что их тяжело использовать в IDE как файлы проектов из-за сложности парсинга настроек, в следствии чего все IDE используют свои собственные форматы (.sln, .vcproj, .bpr и т.д.), которые невозможно использовать с компилятором через командную строку. А многие девелоперы предоставляют только эти файлы. Хочется универсальности.

Кстати, CMake может генерировать не только Makefile'ы, но и файлы проектов для популярных сред.

[igor_bogomolov]

BRE, спасибо. Это меня устраивает
А CPack и CTest вы не используете?

[BRE]

BRE, спасибо. Это меня устраивает
А CPack и CTest вы не используете?

Лучше на ты.

Нет, к сожалению не видал.
До этого использовал autotools. Сейчас, не использую...

[BRE]

Еще один важный момент...
CMake имеет все средства для автоматического поиска и настройки сторонних библиотек (не только Qt). У qmake таких средств нет.
Для больших проектов, где по мимо Qt используются и сторонние библиотеки, это сильно упрощает сборку. По крайней мере, на платформах у которых есть фиксированные места расположения библиотек. На венде это не особо важно, т.к. библиотеки можно собрать и установить в любых директориях и указывать пути все равно придется вручную. Кстати, для этого у CMake есть специальная оконно-консольная утилита ccmake.