Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Вопрос только один — почему не GYP?
«Так повелось» © Извините, что грубо, но данный пост про cmake.
Ну знаете, вы меня извините пожалуйста, но это не ответ. Я хотел узнать почему именно cmake, а не какая-нибудь другая более новая система?
Я имею право не отвечать на вопрос?
И все же, было бы интересно: Почему именно он?
Сейчас собираюсь применять, а для этого мне надо подружить CMake с Doxygen, Boost.Test, Precompiled headers компиляцией и Запуском некоторых кастомных python-скриптов тестирующих собранное. Было бы круто если вы все же ответили )
Сейчас собираюсь применять, а для этого мне надо подружить CMake с Doxygen, Boost.Test, Precompiled headers компиляцией и Запуском некоторых кастомных python-скриптов тестирующих собранное. Было бы круто если вы все же ответили )
Просматривая большие проекты в поисках замены autotools, увидел cmake, потом scons — они известны, они используются; сравнив выбрал cmake. Gyp тоже видел, не понравился. Я с этим ничего не могу поделать.
>>Gyp тоже видел, не понравился.
Не понравился чем конкретно? Мы же не девушки выбирающие сумку по цвету там туфель или еще чего-нить.
Пока вижу плюсы у Gyp, хоть и узнал о нем не больше часу назад.
+ На Json, этот формат сейчас чуть ли не все языки программирования знают что дает в случае чего писать свои кастомные скрипты для решения каких-либо задач;
+ Более читабелен синтаксис, а я пытался разобраться с CMake-синтаксисом, но поняв что достаточно сложен и поэтому отложил «на потом»;
Не понравился чем конкретно? Мы же не девушки выбирающие сумку по цвету там туфель или еще чего-нить.
Пока вижу плюсы у Gyp, хоть и узнал о нем не больше часу назад.
+ На Json, этот формат сейчас чуть ли не все языки программирования знают что дает в случае чего писать свои кастомные скрипты для решения каких-либо задач;
+ Более читабелен синтаксис, а я пытался разобраться с CMake-синтаксисом, но поняв что достаточно сложен и поэтому отложил «на потом»;
Пожалуйста, прекратите переубеждать меня в том, что нравится вам. Да и почему вы думаете, что программист не может выбирать себе autotool исходя из того, нравится синтаксис или нет? :)
Никто не убеждает. Вас просят перечислить список недостатков которые вы заметили в Gyp в результате которых вы приняли решение что не нравится? Это только из-за синтаксиса Gyp, правильно понял?
Я не могу найти — может ли gyp искать сторонние библиотеки, судя по всему — нет. В таком случае, имхо, это его критический недостаток для многих проектов.
Я не собираю стопитсот зависимых проектов одновременно, если вы намекаете на какое-то особое удобство gyp в этом деле. Только из-за json синтаксиса. Может быть есть особенности функционала свои, но я их не изучал в виду того, что откинул его сразу. Вот SCons да, тот изучал и мне он даже показался проще cmake. Но изучать из-за scons питон времени не было. Так повелось ©
Про precompiled headers + cmake можно посмотреть тут: www.cmake.org/Bug/view.php?id=1260.
ещё есть github.com/sakra/cotire
Может быть, вы вкратце поясните, чем gyp лучше cmake? Не могу найти сходу ни одного преимущества за исключением спорной новизны.
Как указано в следующем комментарии — здесь все подробно описано code.google.com/p/gyp/wiki/GypVsCMake. А если брать в расчет удобства для меня как для разработчика:
- Только одна зависимость — python, который, к слову, по-умолчанию доступен в большинстве дистрибутивов linux.
- Можно генерировать .ninja файлы ( martine.github.com/ninja/ ), а, с их помощью, очень быстро компилировать проекты.
- Легкий и понятный псевдо-JSON синтаксис
Вы предлагаете, например, для сборки проекта на C тащить ещё и Python? Но зачем? Весь мир сошёл с ума с интерпретируемыми языками.
CMake прекрасен тем, что действительно работает на чём угодно и при этом не тащит за собой никаких зависимостей.
CMake прекрасен тем, что действительно работает на чём угодно и при этом не тащит за собой никаких зависимостей.
CMake тоже прекрасно работает с ninja.
cmake тоже поддерживает ninja.
И компиляция всего MySQL этим ninja нисколько не быстрее, чем GNU make, даже медленнее.
И компиляция всего MySQL этим ninja нисколько не быстрее, чем GNU make, даже медленнее.
И еще одно — GYP может генерировать не только Makefile, но и xcodeproject и vcproject тоже.
CMake тоже это умеет. Например, «cmake -G Xcode» для xcodeproject.
cmake тоже умеет генерировать не только Makefile, иначе в нем не было бы смысла. список генераторов: www.cmake.org/cmake/help/v2.8.9/cmake.html#section_Generators
Согласен, не увидел этого.
А вот как у cmake обстоит дело с зависимостями? Допустим у меня есть библиотека с cmake файлом (и 500+ C файлами), которую я хочу использовать в своем cmake проекте (не добавляя эти 500 файлов руками). Может ли cmake подключить ее?
А вот как у cmake обстоит дело с зависимостями? Допустим у меня есть библиотека с cmake файлом (и 500+ C файлами), которую я хочу использовать в своем cmake проекте (не добавляя эти 500 файлов руками). Может ли cmake подключить ее?
Вы про TARGET_LINK_LIBRARIES в cmake?
Да, может. Что то в духе:
file (GLOB_RECURCE my_srcs *.c)
add_library(mylibrary SHARED my_srcs)
Это конечно хорошо, но допустим там есть разные файлы для разных платформ (проще говоря сложная логика). Вы же не собираетесь полностью скопировать все зависимости и логику из cmakefile библиотеки?
Подождите, вы что сейчас хотите доказать? Ну хорош ваш GYP, ну и что? Статья про Cmake, и многим интересна. Напишите про GYP, так же почитаем с удовольствием.
Судя по вашей логике, статей, например, про ассемблер, уже лет двадцать-тридцать как не должно быть, ведь придумали же… где… и т.д.
Судя по вашей логике, статей, например, про ассемблер, уже лет двадцать-тридцать как не должно быть, ведь придумали же… где… и т.д.
Ну я надеюсь, весь платформеный код лежит в отдельных папках (ну или по крайней мере есть способ отобрать файлы с помощью тех же глобов). Никто не запрещает указать несколько списков файлов в качестве параметра add_library или, наоборот, собрать сначала нужные исходники в один список, а потом отдать их в add_library. Получится что то в духе этого:
В целом CMake принято ругать скорее за сложный синтаксис, чем за недостаток фич.
file (GLOB_RECURCE my_common_srcs *.c)
if (WIN32)
file(GLOB_RECURCE my_platform_srcs win32/*.c)
else()
...
endif()
add_library(mylibrary SHARED my_common_srcs my_platform_srcs)
В целом CMake принято ругать скорее за сложный синтаксис, чем за недостаток фич.
Еще есть один нюанс cmake, то что после добавление нового файла в каталог с исходниками нужно ЗАНОВО перегненирировать все файлы для всех build modes (при использовании масок типа *.cpp). Хотя конечно это отражено в описании cmake, т.к. cmake это не система сборки, это всего лишь генератор файлов для сборки и в этом его и плюс и минус. Минус я считаю достаточно большой, т.к. подобные системы не могут живо реагировать на изменение рабочего окружения, и чем больше и сложнее проект, тем больше вероятность что-то упустить из виду.
Спасибо, я не знал что существует столь интересный проект )
Но Qt пользуются cmake и никто не жалуется.
Гм, что? Qt сейчас собирается с помощью configure + qmake. Приложения, использующие Qt, обычно собираются с помощью qmake. В планах переход на Qt Build Suite. Причем тут cmake?..
К слову, cmake для MSVS/XCode/CodeBlocks/etc генерирует не Makefile'ы, а проектные файлы для соответствующих IDE.
Не будет ли уместно запостить в *nix? Понятно что технология кросплатформенная, но все же
На хабре как раз нехватало туториала по CMake, даже сам думал написать :)
Ога, официальная дока заставляет писать с бубном, но на просторах инэта есть и на русском, которые хоть как-то поясняют как эта магия работает
Ну оно не сильно сложно, но гуглить иногда приходится, да.
Ага, там далеко не всё очевидно и иногда попадаются забавные баги типа того, что на Mac OS X оно всегда декларирует систему как 32-битную и приходится писать вот такое, например:
IF (CMAKE_SYSTEM_PROCESSOR MATCHES "^(i.86|x86|x86_64)$")
INCLUDE(CheckTypeSize)
CHECK_TYPE_SIZE("void*" SIZEOF_VOID_P BUILTIN_TYPES_ONLY)
IF (${SIZEOF_VOID_P} EQUAL 8)
SET(CMAKE_SYSTEM_PROCESSOR x86_64)
ELSE()
SET(CMAKE_SYSTEM_PROCESSOR i386)
ENDIF()
ENDIF()
У них есть багтрекер :) Да и разработчики вменяемые люди, так что стоит туда отчет отправить.
У них в багтрекере оно уже очень давно есть, однако воз и ныне там.
И это, в общем, практически везде так. Я по этой причине давно забил общаться с opensource-проектами. Последний раз постил года полтора назад баг в SWT, связанный с отображением фона контрола на Mac OS X, так его до сих пор не пофиксили, хотя уже несколько релизов прошло. Про своё общение с командой BSD я вообще предпочитаю не вспоминать, ибо это тоска.
И это, в общем, практически везде так. Я по этой причине давно забил общаться с opensource-проектами. Последний раз постил года полтора назад баг в SWT, связанный с отображением фона контрола на Mac OS X, так его до сих пор не пофиксили, хотя уже несколько релизов прошло. Про своё общение с командой BSD я вообще предпочитаю не вспоминать, ибо это тоска.
Частично соглашусь, не все мои ошибки, про которые я писал отчеты в опенсорсных проектах исправлялись, но я бы не сказал толку их писать нет.
С CMake у меня был такой опыт. Мне нужен был определенный функционал, я написал модуль и решил передать его в апстрим. Мне рассказали, что надо дооформить, кое-где подправили, в общем всячески помогали.
Так что если можете не только отчет написать, но и исправить ошибку — думаю, ваш патч примут.
Это же оперсорс — кто угодно может принять участие в разработке и вы тоже :)
С CMake у меня был такой опыт. Мне нужен был определенный функционал, я написал модуль и решил передать его в апстрим. Мне рассказали, что надо дооформить, кое-где подправили, в общем всячески помогали.
Так что если можете не только отчет написать, но и исправить ошибку — думаю, ваш патч примут.
Это же оперсорс — кто угодно может принять участие в разработке и вы тоже :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем Cmake для автоматической генерации makefile в проектах