пятница, 22 апреля 2016 г.

[prog] MxxRu-обертка над CMake задышала...

...и начала подавать признаки жизни в реальных, жизненных сценариях :) Вот пример MxxRu-обертки вокруг библиотеки SOCI и бэкэнда для PostgresSQL. Это содержимое файла soci/prj.rb:

require 'mxx_ru/cpp'

MxxRu::Cpp::ext_cmake_project {
  where 'soci'
  with WITH_BOOST:ON,
     WITH_ORACLE:OFF,
     SOCI_EMPTY:OFF,
     SOCI_SHARED:ON,
     SOCI_STATIC:OFF,
     SOCI_TESTS:OFF

  includedir_subfolder "soci"
  includedir_subfolder "soci/postgresql"

  include_path "/usr/include/postgresql"MxxRu::Cpp::Target::OPT_UPSPREAD

  lib 'soci_core'
  lib 'soci_postgresql'
}

А вот как он используется в другом проектном файле:

require 'mxx_ru/cpp'

MxxRu::Cpp::dll_target {

  target 'soci_db_pool'

  implib_path 'lib'

  define 'SOCI_DB_POOL__PRJ'

  required_prj 'spdlog/prj.rb'
  required_prj 'so_5/prj.rb'
  required_prj 'soci/prj.rb'

  cpp_source 'a_db_pool.cpp'
}

Такими темпами в понедельник можно будет MxxRu-1.6.11 выпускать :)

среда, 20 апреля 2016 г.

[prog] Смотрю тут в доку по Bazel-у и вижу что-то очень знакомое...

Смотрю в раздел Getting Started для C++ проектов в Google-овской системе сборки Bazel. В качестве примера они предлагают несложную структуру проекта и содержимое нескольких проектных файлов для сборки. Интересно сравнить, как это выглядело бы с использованием Mxx_ru. Итак:

[prog.flame] Почему просто не плюнуть на все и не перейти на CMake?

В мире временами происходят вещи, которые мне не понятны. Например, мне до сих пор не понятно, почему была популярна группа "Ласковый май" :) А сейчас непонятно, почему де-факто стандартом в мире 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-файлов для них перевешивает все достоинства этих самых генераторов.

вторник, 19 апреля 2016 г.

[prog] Mxx_ru-1.6.10 с обновлением MxxRu::externals

Mxx_ru обновился до версии 1.6.10 (актуальная точная версия на данный момент 1.6.10.1)

Установить Mxx_ru можно командой gem install Mxx_ru

Обновить Mxx_ru можно командой gem update Mxx_ru

Так же Mxx_ru можно загрузить с SourceForge (gem-файл).

В версии 1.6.10 MxxRu::externals теперь может самостоятельно обнаруживать, что изменилось в файле описаний внешних зависимостей и предпринимать соответствующие действия. Подробнее под катом.