crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в To make, or not to make (вот в чём вопрос)
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Litkevich Yuriy Дата 14.10.2009, 20:03
 
Цитата(igor_bogomolov @ 14.10.2009, 1:22) *
Как сделать так, чтобы CMakeLists.txt оставался в корневой директории, а фалы компиляции и все то что создаёт сам CMake, перенаправить в какую-нибудь другую папочку?
Я, при сборке eXaro, использовал CMake-gui (в виндовозном дистрибе есть), нужно открыть каталог с корневым CMakeLists.txt, указать каталог для мусора (объектников и т.п.), Заполнить параметры (лучше в режиме "Simple View"), нажать кнопку "Configure", если всё удачно, то нажимаем "Generate" (будут созданы make-файлв в каталоге для мусора, там и командуешь make)

продолжение этой темы в лаборатории
к стати тема важная имеет смысл там голосовать (в первой теме, ну а теперь и во второй)
BRE Дата 14.10.2009, 7:47
  Еще один важный момент...
CMake имеет все средства для автоматического поиска и настройки сторонних библиотек (не только Qt). У qmake таких средств нет.
Для больших проектов, где по мимо Qt используются и сторонние библиотеки, это сильно упрощает сборку. По крайней мере, на платформах у которых есть фиксированные места расположения библиотек. На венде это не особо важно, т.к. библиотеки можно собрать и установить в любых директориях и указывать пути все равно придется вручную. Кстати, для этого у CMake есть специальная оконно-консольная утилита ccmake.
BRE Дата 13.10.2009, 22:27
 
Цитата(igor_bogomolov @ 13.10.2009, 23:22) *
BRE, спасибо. Это меня устраивает :)
А CPack и CTest вы не используете?

Лучше на ты.

Нет, к сожалению не видал.
До этого использовал autotools. Сейчас, не использую... ;)
igor_bogomolov Дата 13.10.2009, 22:22
  BRE, спасибо. Это меня устраивает :)
А CPack и CTest вы не используете?
BRE Дата 13.10.2009, 22:21
 
Цитата(SABROG @ 13.10.2009, 23:00) *
На сколько я помню у CMAKE есть еще проблема с включением консоли (CONFIG += console). По умолчанию она выключена и чтобы её включить надо менять флаги конкретного компилятора. Т.е. уже как минимум надо писать условие типа если это компилятор gcc, msvc, bcc, icc, то чтобы включить консоль надо передать такой-то флаг, вместо универсального ключа в CONFIG.

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

Цитата(SABROG @ 13.10.2009, 23:00) *
- какие-то костыльные функции QT4_* (а QT3_* там есть вообще?)

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

Цитата(SABROG @ 13.10.2009, 23:00) *
- не родная система сборки. Тролли что-то поменяют или добавят и не известно, когда за ними поспеют девелоперы CMake.

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

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

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

Цитата(SABROG @ 13.10.2009, 23:00) *
- синтаксис CMake скриптов похож на язык Си (сплошные вызовы функций) и Basic одновременно из-за вечно UPPERCASE'ных их названий.

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

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

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

Кстати, CMake может генерировать не только Makefile'ы, но и файлы проектов для популярных сред.
SABROG Дата 13.10.2009, 22:00
  На сколько я помню у 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 Дата 13.10.2009, 22:00
  С 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, в которых собирать отладочную и релизную сборку.


igor_bogomolov Дата 13.10.2009, 21:22
 
Цитата(BRE @ 13.10.2009, 8:58) *
Вот рабочий 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 на это не способен?
kwisp Дата 13.10.2009, 8:51
 
Цитата(BRE @ 13.10.2009, 9:31) *
А если он эту программу распространять захочет? Он что делать будет?
С учетом того, что необходимые библиотеки у пользователя могут не стоять, стоять не там, где у автора и т.д.
А если пользователь еще и не разработчик, то вероятность успешной сборки проекта будет стремиться к нулю.

вопросы понял.
обязательно поинтересуюсь как он свои проекты распространяет.
BRE Дата 13.10.2009, 8:31
 
Цитата(kwisp @ 13.10.2009, 9:19) *
знаю человека он к своим проектам простой makefile один раз написал и пользуется.(кстати qt он тоже собирает не плохо)

А если он эту программу распространять захочет? Он что делать будет?
С учетом того, что необходимые библиотеки у пользователя могут не стоять, стоять не там, где у автора и т.д.
А если пользователь еще и не разработчик, то вероятность успешной сборки проекта будет стремиться к нулю.
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 12:07