To make, or not to make (вот в чём вопрос) Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Переключить на: Стандартный Линейный

[Litkevich Yuriy]

To make, or not to make (вот в чём вопрос)
Перевод

[trdm]

хотелось бы для тупых в английском краткий рЭзюм.

[Kagami]

Они думают чем заменить qmake и спрашивают мнение у сообщества

[ViGOur]

А зачем менять? Все уже к нему привыкли, плагины и IDE заточены под работу с ним, те ктоторые поддерживают работу с Qt.

[kwisp]

ViGOur,
ну вот если поситать посты то все в восторге от CMake.
почему его так любят не понятно.
надо почитать о нём побольше.

[BRE]

CMake уже давно нормально поддерживает Qt.

[kwisp]

CMake уже давно нормально поддерживает Qt.

мне он не нравится.
хотя имею не много опыта работы с ним.

[BRE]

ну вот если поситать посты то все в восторге от CMake.
почему его так любят не понятно.

Кроссплатформенный, не намного сложней qmake.

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

Раскрывающийся текст

PROJECT( freeremoteq )

CMAKE_MINIMUM_REQUIRED( VERSION 2.6 )

FIND_PACKAGE( Qt4 REQUIRED )
SET( QT_USE_QTDBUS 1 )
SET( QT_USE_QTSCRIPT 1 )
SET( QT_USE_QTXML 1 )
INCLUDE( ${QT_USE_FILE} )

ADD_SUBDIRECTORY( scriptext )
ADD_SUBDIRECTORY( setup )

INCLUDE_DIRECTORIES( ${freeremote_BINARY_DIR} ${setup_BINARY_DIR} ${freeremoteq_BINARY_DIR}
${freeremoteq_SOURCE_DIR} ${scriptext_SOURCE_DIR} ${setup_SOURCE_DIR} )

SET( HEADERS action.h client.h controllerservice.h scriptsystem.h util.h actionmanager.h configuration.h
managerservice.h serversystem.h logmodel.h logviewer.h clientdbusiface.h )
SET( SOURCES action.cpp client.cpp controllerservice.cpp managerservice.cpp serversystem.cpp
actionmanager.cpp configuration.cpp main.cpp scriptsystem.cpp util.cpp logmodel.cpp
logviewer.cpp clientdbusiface.cpp )

QT4_WRAP_CPP( MOC_SOURCES client.h controllerservice.h managerservice.h serversystem.h
actionmanager.h scriptsystem.h logmodel.h logviewer.h clientdbusiface.h )

QT4_ADD_DBUS_ADAPTOR( SOURCES org.bresoft.freeremoteQ.xml clientdbusiface.h ClientDBusIface )

QT4_ADD_RESOURCES( QRC_SOURCES application.qrc )

ADD_EXECUTABLE( freeremoteq ${SOURCES} ${MOC_SOURCES} ${QRC_SOURCES} )
TARGET_LINK_LIBRARIES( freeremoteq scriptext setup ${QT_LIBRARIES} )

INSTALL( TARGETS freeremoteq DESTINATION ${PREFIX}/bin )

Сообщение отредактировал BRE - 13.10.2009, 8:05

[Litkevich Yuriy]

Мне процедура работы с CMake не понравилась (проект eXaro собирал).

А зачем менять? Все уже к нему привыкли

троли говорят, что его тяжело поддерживать, внутри он становится всё сложнее и сложнее.
И вроде как новички в нём тяжело ориентируются.

[BRE]

мне он не нравится.
хотя имею не много опыта работы с ним.

Ну не знаю... Я долго работал с autotools, после знакомства с CMake отказался в пользу последнего.

[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.

[Litkevich Yuriy]

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

Я, при сборке eXaro, использовал CMake-gui (в виндовозном дистрибе есть), нужно открыть каталог с корневым CMakeLists.txt, указать каталог для мусора (объектников и т.п.), Заполнить параметры (лучше в режиме "Simple View"), нажать кнопку "Configure", если всё удачно, то нажимаем "Generate" (будут созданы make-файлв в каталоге для мусора, там и командуешь make)

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