Comments 45
«Так повелось» © Извините, что грубо, но данный пост про cmake.
Ну знаете, вы меня извините пожалуйста, но это не ответ. Я хотел узнать почему именно cmake, а не какая-нибудь другая более новая система?
И все же, было бы интересно: Почему именно он?
Сейчас собираюсь применять, а для этого мне надо подружить CMake с Doxygen, Boost.Test, Precompiled headers компиляцией и Запуском некоторых кастомных python-скриптов тестирующих собранное. Было бы круто если вы все же ответили )
Просматривая большие проекты в поисках замены autotools, увидел cmake, потом scons — они известны, они используются; сравнив выбрал cmake. Gyp тоже видел, не понравился. Я с этим ничего не могу поделать.
>>Gyp тоже видел, не понравился.
Не понравился чем конкретно? Мы же не девушки выбирающие сумку по цвету там туфель или еще чего-нить.

Пока вижу плюсы у Gyp, хоть и узнал о нем не больше часу назад.
+ На Json, этот формат сейчас чуть ли не все языки программирования знают что дает в случае чего писать свои кастомные скрипты для решения каких-либо задач;
+ Более читабелен синтаксис, а я пытался разобраться с CMake-синтаксисом, но поняв что достаточно сложен и поэтому отложил «на потом»;
Пожалуйста, прекратите переубеждать меня в том, что нравится вам. Да и почему вы думаете, что программист не может выбирать себе autotool исходя из того, нравится синтаксис или нет? :)
Никто не убеждает. Вас просят перечислить список недостатков которые вы заметили в Gyp в результате которых вы приняли решение что не нравится? Это только из-за синтаксиса Gyp, правильно понял?
Я не могу найти — может ли gyp искать сторонние библиотеки, судя по всему — нет. В таком случае, имхо, это его критический недостаток для многих проектов.
Я не собираю стопитсот зависимых проектов одновременно, если вы намекаете на какое-то особое удобство gyp в этом деле. Только из-за json синтаксиса. Может быть есть особенности функционала свои, но я их не изучал в виду того, что откинул его сразу. Вот SCons да, тот изучал и мне он даже показался проще cmake. Но изучать из-за scons питон времени не было. Так повелось ©
Может быть, вы вкратце поясните, чем gyp лучше cmake? Не могу найти сходу ни одного преимущества за исключением спорной новизны.
Как указано в следующем комментарии — здесь все подробно описано code.google.com/p/gyp/wiki/GypVsCMake. А если брать в расчет удобства для меня как для разработчика:

  • Только одна зависимость — python, который, к слову, по-умолчанию доступен в большинстве дистрибутивов linux.
  • Можно генерировать .ninja файлы ( martine.github.com/ninja/ ), а, с их помощью, очень быстро компилировать проекты.
  • Легкий и понятный псевдо-JSON синтаксис
Вы предлагаете, например, для сборки проекта на C тащить ещё и Python? Но зачем? Весь мир сошёл с ума с интерпретируемыми языками.

CMake прекрасен тем, что действительно работает на чём угодно и при этом не тащит за собой никаких зависимостей.
А gyp уже не зависимость? Или его каждый таскает за собой прямо в проекте? Кстати например в двух дистрбутивах которыми я пользуюсь gyp нет. А CMake есть везде.
cmake тоже поддерживает ninja.
И компиляция всего MySQL этим ninja нисколько не быстрее, чем GNU make, даже медленнее.
Согласен, не увидел этого.

А вот как у cmake обстоит дело с зависимостями? Допустим у меня есть библиотека с cmake файлом (и 500+ C файлами), которую я хочу использовать в своем cmake проекте (не добавляя эти 500 файлов руками). Может ли cmake подключить ее?
Да, может. Что то в духе:

file (GLOB_RECURCE my_srcs *.c)
add_library(mylibrary SHARED my_srcs)
Это конечно хорошо, но допустим там есть разные файлы для разных платформ (проще говоря сложная логика). Вы же не собираетесь полностью скопировать все зависимости и логику из cmakefile библиотеки?
Подождите, вы что сейчас хотите доказать? Ну хорош ваш GYP, ну и что? Статья про Cmake, и многим интересна. Напишите про GYP, так же почитаем с удовольствием.
Судя по вашей логике, статей, например, про ассемблер, уже лет двадцать-тридцать как не должно быть, ведь придумали же… где… и т.д.
Согласен, статья не помешала бы. Я просто хочу обратить внимание разработчиков на другие системы (cmake, как и любую другую, нельзя назвать совершенной).
Ну я надеюсь, весь платформеный код лежит в отдельных папках (ну или по крайней мере есть способ отобрать файлы с помощью тех же глобов). Никто не запрещает указать несколько списков файлов в качестве параметра add_library или, наоборот, собрать сначала нужные исходники в один список, а потом отдать их в add_library. Получится что то в духе этого:
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.
Пасибо, щас исправлю эту часть. Не в Qt, а стандартное для KDE4.
Не будет ли уместно запостить в *nix? Понятно что технология кросплатформенная, но все же
Ога, официальная дока заставляет писать с бубном, но на просторах инэта есть и на русском, которые хоть как-то поясняют как эта магия работает
Ага, там далеко не всё очевидно и иногда попадаются забавные баги типа того, что на 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 я вообще предпочитаю не вспоминать, ибо это тоска.
Частично соглашусь, не все мои ошибки, про которые я писал отчеты в опенсорсных проектах исправлялись, но я бы не сказал толку их писать нет.
С CMake у меня был такой опыт. Мне нужен был определенный функционал, я написал модуль и решил передать его в апстрим. Мне рассказали, что надо дооформить, кое-где подправили, в общем всячески помогали.
Так что если можете не только отчет написать, но и исправить ошибку — думаю, ваш патч примут.
Это же оперсорс — кто угодно может принять участие в разработке и вы тоже :)
Only those users with full accounts are able to leave comments. Log in, please.