В мире временами происходят вещи, которые мне не понятны. Например, мне до сих пор не понятно, почему была популярна группа "Ласковый май" :) А сейчас непонятно, почему де-факто стандартом в мире C++ становится CMake.
Берешь какую-нибудь библиотеку, скажем, soci, а у нее CMake. И ейный CMakeLists.txt сам ищет то, что ему нужно. А по команде make install ставит библиотеки в подкаталог lib. Или в lib64. А какая-нибудь другая библиотека с CMakeLists.txt ищет то, что ей нужно каким-нибудь другим образом. И библиотеки всегда ставит в подкаталог lib. И если нужно подружить эти две библиотеки в рамках одного проекта, то нужно немного покурить бамбук, дабы разобраться что к чему.
Все это мне не нравится. Но ситуация складывается так, что попытки избежать использования CMake все больше напоминают попытки помочиться против ветра. Посему время от времени приходит мысль: а не засунуть ли свое восприятие прекрасного куда подальше и не перейти ли на CMake полностью? Ну, в конце-концов, сколько можно пытаться быть умнее всех?
Но тут задумываешься о последствиях. Хорошо, думаю, перейду на CMake и начну вести разработку того же SObjectizer-а только под CMake. Во что это выльется?
На платформе Windows у меня сейчас шесть компиляторов (две версии VC++, четыре версии GCC (от MinGW-w64)). Парой из них я пользуюсь постоянно. Остальными -- время от времени. Если бы вместо Mxx_ru я использовал CMake, то мне бы пришлось для проверки под очередным компилятором делать что-то вроде:
mkdir gcc_4_9_3_release
cd gcc_4_9_3_release
cmake -DCMAKE_INSTALL_PREFIX=target -DCMAKE_BUILD_TYPE=Release -G "MinGW Makefiles" ..
mingw32-make install
И так шесть раз только для release-сборок. Если бы потребовалось сделать debug сборку, то пришлось бы проделывать это еще по одному разу. Для каждого компилятора.
Кстати говоря, в большинстве случаев CMake не может сгенерировать sln-файлы для скармливания msbuild-у. У кого-то из них сносит крышу от имен файлов длинее 260-ти символов. Тогда как для nmake обычные make-файлы генерируются без проблем.
Далее у меня под Arch Linux стоит и GCC, и Clang. И CMake-е нужно вручную задавать значения CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, иначе он не может разобраться для чего ему нужно генерировать make-файлы.
Под Ubuntu так же стоят и GCC, и Clang. Но под Ubuntu CMake хотя бы понимает, что штатный компилятор -- это GCC и бодаться с дополнительными настройками нужно только с Clang-ом.
Нет проблем разве что под FreeBSD, где у меня кроме древнего Clang ничего нет. Но и там нужно отдельно генерировать свой набор make-файлов для разных типов build-ов.
А еще, если не ошибаюсь, CMake зафигачивает в make-файлы абсолютные пути к исходным файлам.
Ну вот, блин, не могу я глядя на все это сказать, что CMake предназначен для кроссплатформенной разработки. Может быть его авторы под кроссплатформенной разработкой понимали ситуацию, когда каждый пользователь проекта использует всего одну ОС и всего один компилятор под этой ОС. Тогда понятно. Тогда заморочки только с разными типами сборок.
А уж как посредством CMake делать проект, в котором штук двадцать подпроектов... Тут у меня полные непонятки. В Mxx_ru все просто и привычно: если проект A зависит от B, C и D, то ты просто делаешь у себя в A/prj.rb набор команд required_prj для B/prj.rb, C/prj.rb и D/prj.rb. И все.
Ведь в CMake наверняка можно делать подобные вещи. Но какой ценой?
В общем, Mxx_ru -- это старый велосипед, который хорошо служил все это время. Но он уже старый. Да и я уже старый. Посему с облегчением бы отказался от сопровождения и развития Mxx_ru в пользу чего-нибудь более модного и молодежного. Но вот сделать такой выбор в пользу CMake? На это пойтить пока не могу :)
PS. Кстати говоря, все генераторы нативных make-файлов (будь то CMake, premake5, GYP и иже с ними) сосут по одной и той же причине: когда нужно поддерживать сразу несколько компиляторов, возня с генерацией make-файлов для них перевешивает все достоинства этих самых генераторов.
Комментариев нет:
Отправить комментарий