Показаны сообщения с ярлыком CMake. Показать все сообщения
Показаны сообщения с ярлыком CMake. Показать все сообщения

четверг, 27 марта 2025 г.

[prog.c++.vcpkg] Внезапные приключения с подключением OpenSSL к проекту посредством vcpkg

Есть проект, который собирается под Windows и под Linux. Для управления зависимостями используется vcpkg (вместе с манифестами, т.е. с файлами vcpkg-configuration.json и vcpkg.json, хотя манифесты тут вряд ли виноваты).

В зависимостях есть OpenSSL. Подключение OpenSSL в CMakeLists.txt проекта выглядит стандартным образом:

find_package(OpenSSL CONFIG REQUIRED)
...
target_link_libraries(some_executable_file OpenSSL::SSL OpenSSL::Crypto)

Так вот под Windows все это работает как часы, тогда как под Linux-ом случился нежданчик: внезапно™ выяснилось, что нет таких CMake-овских таргетов, как OpenSSL::SSL и OpenSSL::Crypto.

Вот нет и все, хотя find_package успешно отрабатывает.

Блуждания по потрохам кучи CMake-овских файлов, установленных vcpkg, привело вот к такому фрагменту в файле OpenSSLConfig.cmake, который лежит в vcpkg_installed/x64-linux/share/openssl (извиняюсь за его объем, но здесь все самое важное):

среда, 20 марта 2024 г.

[prog.cmake] Попытался заглянуть в документацию по CMake. Пригорело. Нехило так пригорело :(

Я вот правда не понимаю, как этот кусок говна умудрился стать стандартом де-факто. И еще я не понимаю вот чего: нам, си-плюс-плюсникам, что, мало сложностей и несуразностей в самом C++? Мы так мало набили шишек на граблях C++, что радостно взялись скакать еще и по граблям CMake? Не, реально?

Вообще мне очень неприятно, что и меня, и разработчиков CMake называют программистами. А мне не хочется быть коллегой таких горе-разработчиков. Они уже упороты!

PS. Пожалуйста, не нужно спрашивать у меня чем заменить CMake. Уже почти 20 лет пользуюсь собственной системой сборки, написанной на Ruby. Когда-то даже прикладывал усилия чтобы продвинуть свой лисапед в массы, но не преуспел. На этом считаю свой долг по улучшению C++ной экосистемы полностью выплаченным.

вторник, 8 июня 2021 г.

[prog.wtf] Ну вот правда, как с этим жить?

Честно, не представляю себе, как можно дальше жить в мире, где нормальным считается применение инструмента, провоцирующего на написание чего-то вроде:

add_executable(myapp main.cpp foo.c bar.cpp zot.cu)
target_compile_definitions(myapp
  PRIVATE $<$<COMPILE_LANG_AND_ID:CXX,AppleClang,Clang>:COMPILING_CXX_WITH_CLANG>
          $<$<COMPILE_LANG_AND_ID:CXX,Intel>:COMPILING_CXX_WITH_INTEL>
          $<$<COMPILE_LANG_AND_ID:C,Clang>:COMPILING_C_WITH_CLANG>
)

Если кто не в курсе (счастливчики!), то здесь условные операторы в угловых скобках. Вложенные.

И если бы не специальная поддержка в CMake магической COMPILE_LANG_AND_ID, то приведенный выше фрагмент пришлось бы записать вот так:

target_compile_definitions(myapp
  PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG>
          $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL>
          $<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG>
)

Я даже уже не пытаюсь представить какому сумрачному гению это все пришло в голову. Более того, я даже не пытаюсь больше понять, почему такое количество разработчиков готовы с этим мирится. Ну вот таков мир, что поделать, остается принимать его каков он есть.

Однако, никогда у меня не бывает настолько же сильного желания уйти навсегда из С++, как в случаях, когда самому приходится погружаться в CMake-код. Да и не только из мира C++, но и вообще из программирования.

PS. Месяца четыре назад была возможность послать C++ к чертям собачим не нарушая никаких обязательств. Почему не воспользовался... Эх.

понедельник, 27 ноября 2017 г.

[prog] Ссылки, которые помогли мне в борьбе с CMake

Вроде как удалось забороть CMake и получить то, что хотелось. Зафиксирую в склерознике несколько ссылок, которые помогли лично мне. Может быть они помогут еще кому-нибудь.

Сразу скажу, что это ссылки на уже более-менее продвинутый материал. Если у вас нет опыта работы с CMake вообще, то нужно начать с чего-нибудь совсем простого. Благо тривиальных примеров работы с CMake в Сети очень много. Такое ощущение, что любой чайник, которому удалось самостоятельно собрать с помощью CMake простой HelloWorld из одного cpp-файла, считает своим долгом написать развернутую статью о том, как пользоваться CMake. В подавляющем большинстве все эти статьи ни о чем и на 90% повторяют друг друга. Из толковых вводных материалов я бы отметил вот этот репозиторий с примерами.

Если же говорить о более продвинутых материалов, то:

Две презентации от Daniel Pfeifer: "CMake - Introduction and best practices" и "Effective CMake". Для тех, кто пытается жить с современным CMake, эти презентации, как говорится, must have and must read.

Очень мне помог краткий тутуриал по использованию CMake от проекта KDE. Вроде как там ничего секретного не раскрывается. Но именно там мне стало понятно, как делаются какие-то вещи.

В качестве примеров CMake-файлов помогли исходники проектов Cinder и AWS SDK C++.

Ну и куда же без официальной документации по самому CMake. Для меня основным мануалом стал раздел cmake-packages (ну и ссылки оттуда на другие документы). Не скажу, что описано толково и понятно. Но вкурить, в конце-концов, удалось.

Надеюсь, эти ссылки помогут в освоении современного CMake.


За минувшую неделю я уже достаточно набросил на CMake. Но, даже после того, как мне удалось его более-менее забороть, я все равно думаю, что если CMake -- это лучшее, что C++-сообщество смогло для себя сделать, и если CMake -- это и есть то "светлое" будущее, которое ждет мир C++, то C++ вместе с его миром и "светлым будущим" под ручку с CMake нужно закапывать. Быстро и безжалостно.

пятница, 24 ноября 2017 г.

[prog.c++] Альфа-версия обновленной поддержки CMake в SObjectizer

Задышала первая версия обновленных CMake-скриптов для SObjectizer-5.5.20. Взять и попробовать можно вот из этого архива. Взять и попробовать очень желательно, ибо сами мы не местные CMake в своей работе не используем. Поэтому на своих повседневных задачах проверить правильность сделанных CMake-скриптов не можем. А вот тем, кто использует SObjectizer именно через CMake наши изменения могут помочь. Или навредить :)

Итак, что было сделано? Было сделано так, чтобы SObjectizer можно было через CMake собрать, затем выполнить make install, затем задействовать у себя в проекте посредством find_package.

Попробую пояснить на пальцах. Для Unix-подобных систем, т.к. там проще.

Скачиваем архив с SObjectizer-ом, распаковываем его: unzip so-5.5.20-alpha2-201711251230.zip и заходим в образовавшийся каталог so-5.5.20-alpha2-201711251230. Там выполняем следующие действия:

mkdir cmake_build
cd cmake_build
cmake ../dev
cmake --build . --config Release
cmake --build . --config Release --target install

Будет скомпилирован только SObjectizer в виде статической и динамической библиотек. После этого он будет установлен в стандартных для вашего Unix-а путях (например, в /usr/local/include, /usr/local/lib).

Если у вас CMake-3.8 или более новый, то для того, чтобы использовать SObjectizer в своем CMake проекте вы пишете что-то вроде:

cmake_minimum_required(VERSION 3.1)

project(hello_world)

find_package(so_5 5.5.20 REQUIRED)

add_executable(hello_world_static hello_world.cpp)
target_link_libraries(hello_world_static so_5::StaticLib)

Тут строится приложение hello_world_static, которое линкуется к статической версии SObjectizer-а.

Если нужно слинковаться с динамической библиотекой SObjectizer-а, тогда пишете что-то вроде:

cmake_minimum_required(VERSION 3.1)

project(hello_world)

find_package(so_5 5.5.20 REQUIRED)

add_executable(hello_world_shared hello_world.cpp)
target_link_libraries(hello_world_shared so_5::SharedLib)

Ну и компилируете это обычным образом.

Если же вы под Windows или не хотите гадить в своем уютненьком Unix-е в стандартные пути для размещения библиотек, то можно поступить, например, так (предполагаем, что ~ -- это ваш рабочий каталог, в рамках которого вы хотите оставаться, и в который вы уже скачали so-5.5.20-alpha2-201711251230.zip):


~$ unzip so-5.5.20-alpha2-201711251230.zip
~$ cd so-5.5.20-alpha2-201711251230
~/so-5.5.20-alpha2-201711251230$ mkdir cmake_build
~/so-5.5.20-alpha2-201711251230$ cd cmake_build
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake -DCMAKE_INSTALL_PREFIX=target -G "Visual Studio 12 2013" ../dev
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake --build . --config Release
~/so-5.5.20-alpha2-201711251230/cmake_build$ cmake --build . --config Release --target install
~/so-5.5.20-alpha2-201711251230/cmake_build$ cd ~/hello_world
~/hello_world$ mkdir cmake_build
~/hello_world/cmake_build$ cmake -DCMAKE_PREFIX_PATH=~/so-5.5.20-alpha2-201711251230/cmake_build/target -G "Visual Studio 12 2013" ..
~/hello_world/cmake_build$ cmake --build . --config Release

Для Unix-а, естественно, придется поменять значение в -G (либо вообще -G не указывать, т.к. под Unix-ами обычно имеется всего один тулсет).

Если у вас более старый CMake, чем CMake-3.8, то придется выполнить в своих CMakeLists.txt дополнительные действия: нужно указать, что вам требуется C++11. Например, это можно сделать в вашем главном CMakeLists.txt:

cmake_minimum_required(VERSION 3.1)

set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

project(hello_world)

find_package(so_5 5.5.20 REQUIRED)

add_executable(hello_world_shared hello_world.cpp)
target_link_libraries(hello_world_shared so_5::SharedLib)

Пример того, как можно подключать SObjectizer через find_package, можно увидеть в этом репозитории (см. dev/CMakeLists.txt).


Вообще говоря, должен продолжать работать и другой сценарий использования SObjectizer и CMake. Вы можете включить SObjectizer в свое дерево исходников. Чтобы у вас было что-то вроде:


~/your_project_root
  `- so_5/
  `- timertt/
  `- your_another_project/
  `- your_main_project/
  ...
  CMakeLists.txt

И вот в своем главном CMakeLists.txt вы имеете возможность сделать просто add_subdirectory(so_5) и все. Далее вы должны получить возможность использовать so_5::StaticLib и so_5::SharedLib в своих CMake-овских командах target_link_libraries.

Пример того, как можно подключать SObjectizer через add_subdirectory, можно увидеть в этом репозитории (см. dev/CMakeLists.txt).


В общем, еще раз просьба к тем, кто использует SObjectizer совместно с CMake: попробуйте новую версию. Любой фидбек нам будет полезен и поможет сделать поддержку CMake более удобной.

среда, 22 ноября 2017 г.

[prog.c++] Что и как следует улучшить в CMake-овских скриптах для SObjectizer?

Благодаря помощи Алексея Сырникова в SObjectizer уже несколько лет есть поддержка CMake. Сейчас, по ходу разработки очередной версии, мы хотим улучшить эту поддержку. Посему обращаемся ко всем, кто пытался использовать SO-5 и CMake с вопросами:

Что вам мешало в существующих CMake-скриптах для SO-5?

Чего вам не хватает в существующих CMake-скриптах для SO-5?

Что вам хотелось бы видеть в CMake-скриптах для SO-5?

К счастью, сами-то мы не настоящие сварщики пользуемся CMake, поэтому нам самим сложно судить о том, насколько удобны или неудобны существующие скрипты. Соответственно, нужна помощь тех, кто попробовал воспользоваться CMake для SO-5 и столкнулся с какими-либо сложностями/проблемами/недостатками.

четверг, 18 мая 2017 г.

[prog] Почему-то сильно не хочется делать CMake основным build-tool-ом

Под влиянием вот этого доклада с C++ CoreHard Spring 2017 решил попробовать еще раз посмотреть в сторону CMake как основного своего build-tool-а. Сам CMake, как по мне, говном был, говном и остался. Но, поскольку люди всерьез интересуются такими построенными поверх CMake вещами, как Conan.io и Hunter, то может пришло время зажать нос и научиться обмазываться CMake-ом?

В чем у меня специфика? В том, что под Windows у меня сейчас, например, десять(!) вполне себе актуальных версий GCC под x64: 4.8, 4.9, 5.1, 5.2, 5.3, 5.4, 6.1, 6.2, 6.3 и 7.1. Плюс к тому три версии Visual Studio (каждая из которых как в x86, так и в x64). Плюс две версии clang (3.9 и 4.0).

Под каждую версию компилятора у меня есть свой bat-файл, в котором настраиваются все пути и все окружение. И для каждого батничка свой ярлык на рабочем столе. Нужен мне, скажем, gcc-4.8, я кликаю на ярлык, попадаю в нужную среду, захожу в нужный мне каталог, запускаю ruby build.rb или ruby some/project/prj.rb. И все.

пятница, 30 сентября 2016 г.

[prog.flame] portfile.cmake из Vcpkg супротив рецепта для MxxRu::externals

Попробовал представить, как сделать адаптацию SO-5 под новую волшебную пилюлю от Microsoft под названием Vcpkg. Проблевался. Какую только херню, пардон май френч, народ готов жрать только потому, что эта херня от MS или от Google. Поразительно.

Суть Vcpkg в том, что под каждый проект, который хочется затянуть в этот самый Vcpkg, нужно создать файлик portfile.cmake, в котором будут находится инструкции по доставанию исходников этого проекта и по его сборке (если проект нуждается в сборке). Для примера покажу, как выглядит portfile.cmake для библиотеки Range-V3. И как это же самое выглядит в виде рецепта для MxxRu::externals.

Итак, portfile.cmake для Vcpkg:

include(vcpkg_common_functions)
set(SOURCE_PATH ${CURRENT_BUILDTREES_DIR}/src/Range-V3-VS2015-ede9ad367fd5ec764fecb039c874614bd908e6b6)
vcpkg_download_distfile(ARCHIVE
    URLS "https://github.com/Microsoft/Range-V3-VS2015/archive/ede9ad367fd5ec764fecb039c874614bd908e6b6.zip"
    FILENAME "range-v3-ede9ad367fd5ec764fecb039c874614bd908e6b6.zip"
    SHA512 e978c7694471d8616c248647b77689f377b3e2517347abde8629b140e5994de8bf686565a24cdd7dd222f325d43b775f5e478c91220dce75313985499b134637
)
vcpkg_extract_source_archive(${ARCHIVE})

file(COPY ${SOURCE_PATH}/LICENSE.txt DESTINATION ${CURRENT_PACKAGES_DIR}/share/range-v3)
file(RENAME ${CURRENT_PACKAGES_DIR}/share/range-v3/LICENSE.txt ${CURRENT_PACKAGES_DIR}/share/range-v3/copyright)
file(INSTALL ${SOURCE_PATH}/include DESTINATION ${CURRENT_PACKAGES_DIR} FILES_MATCHING PATTERN "*.hpp")
vcpkg_copy_pdbs()

Тоже самое для MxxRu::externals:

MxxRu::arch_externals :range_v3_vs2015 do |e|
  e.url 'https://github.com/Microsoft/Range-V3-VS2015/archive/ede9ad367fd5ec764fecb039c874614bd908e6b6.zip'
  e.sha512 'e978c7694471d8616c248647b77689f377b3e2517347abde8629b140e5994de8bf686565a24cdd7dd222f325d43b775f5e478c91220dce75313985499b134637'

  e.map_dir 'include/*' => 'dev/range-v3'
  e.map_file 'LICENSE.txt' => 'dev/range-v3/*'
end

Резюмируя. Если кому-то действительно нужно, чтобы SO-5 был доступен из портов Vcpkg, то дайте знать. Мы сделаем. Но только если это кому-то действительно нужно. Ибо Vcpkg выглядит как говно и пахнет как говно. А посему вмазываться в говно и сопровождать потом это говно просто так не хочется, только если на то будут причины.

пятница, 10 июня 2016 г.

[prog.cmake] Как посредством CMake собрать и dynamic- и static-library из одних и тех же исходников?

Потихонечку реализуется список хотелок для SO-5.5.17. На очереди пункт про сборку SObjectizer-а в виде статической библиотеки. Для Mxx_ru проектные файлы уже подправлены и SO-5 через Mxx_ru можно собрать и как dynamic-, и как static-library. А вот как сделать то же самое через CMake не знаю. Буду признателен, если кто-нибудь из читателей подскажет, как вот этот CMakeLists.txt нужно переделать (он же на github-е).

четверг, 14 апреля 2016 г.

[prog] Поясните про использование CMake, пожалуйста

Поскольку все больше и больше C++ных проектов использует CMake, то приходится учится работать с такими проектами. Но есть вещи, которые пока не понятны. Поэтому буду признателен читателям, если меня просветят и/или подскажут, где именно что-нибудь полезное можно прочитать.

Первый непонятный момент. Допустим, есть простая ситуация: Linux и всего два компилятора -- gcc и clang. Мне нужно пользоваться то тем, то другим. При этом компилироваться как в release-режиме, так и в debug. Правильно ли я понимаю, что каноническим решением является вот такое:

cd ~/develop/my-project
mkdir build_gcc_release
cd build_gcc_release
cmake -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=Release ..
cd ..
mkdir build_gcc_debug
cd build_gcc_debug
cmake -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=gcc -DCMAKE_BUILD_TYPE=Debug ..
mkdir build_clang_release
cd build_clang_release
cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release ..
cd ..
mkdir build_clang_debug
cd build_clang_debug
cmake -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Debug ..

Второй непонятный момент. Допустим, мне нужно использовать три внешних проекта (p1, p2, p3), у которых сборка делается через CMake. При этом я хочу, чтобы результаты компиляции всех трех подпроектов (т.е. исполнимые файлы и so-ки) сбрасывались в одни и те же каталоги. Т.е. вместо того, чтобы иметь что-то вроде p1/build/lib b p1/build/bin, p2/build/lib и p2/build/bin, p3/build/lib и p3/build/bin, я хочу иметь my-project/build/lib и my-project/build/bin.

Правильно ли я понимаю, что в этом случае у меня получается что-то вроде:

cd ~/develop/my-project
wget https://p1.home/download/p1-some-ver.tar.gz
tar -xf p1-some-ver.tar.gz
cd p1-some-ver
mkdir build_gcc_release
cd build_gcc_relese
cmake -DCMAKE_INSTALL_PREFIX=~/develop/my-project/build -DCMAKE_BUILD_TYPE=Release ..
make install
cd ../..

wget https://p3.home/download/p2-some-ver.tar.gz
tar -xf p2-some-ver.tar.gz
cd p2-some-ver
mkdir build_gcc_release
cd build_gcc_relese
cmake -DCMAKE_INSTALL_PREFIX=~/develop/my-project/build -DCMAKE_BUILD_TYPE=Release ..
make install
cd ../..

...

Т.е. я создаю compiler-specific makefiles для каждого из подпроектов, но при этом для всех подпроектов указываю общее значение CMAKE_INSTALL_PREFIX?

среда, 22 октября 2014 г.

[prog.c++] А как принято пользоваться CMake?

Благодаря ув.тов.Alex Syrnikov в SO-5.5 появился набор CMakeLists.txt-файлов для сборки смой библиотеки so-5.5 и примеров. Сейчас все это дело находится в рабочей ветке репозитория и готовится к релизу в виде версии 5.5.2. Но, поскольку сам я никогда с CMake дела не имел, то не очень понимаю, как должна выглядеть нормальная поддержка CMake в C++ном проекте.

Есть ли какие-то общепринятые или наиболее распространенные способы использования CMake?

Или же разработчики проекта просто кидают внутрь своих исходников CMakeLists.txt, а пользователь сам уже бабахается с генерацией нужного ему хозяйства из CMakeLists.txt?

Так же интересует вопрос: принято ли в документации к проекту описывать, как из проектного CMakeLists.txt пользователь может сгенерировать нужные ему файлы? Или же просто указывается, что для сборки проекта нужен CMake и на этом все объяснение заканчивается?

PS. Повторюсь, с CMake дел не имел от слова совсем. Штудировать тонны документации или покупать книжки по этому уродскому инструменту желания нет от слова вовсе :) Посему прошу ткнуть пальцев в хорошие примеры того, как это сделано у нормальных людей :)

PPS. Холивара ради ;) Нормальные инструменты - это, в первую очередь, SCons и MxxRu, как же иначе ;) Даже Jam-ы разных оттенков (Perforce, FT или Boost) нормальнее CMake будут :)

пятница, 15 мая 2009 г.

В чем секрет CMake?

Время от времени попадаются сообщения о том, что очередной проект перебирается на build-систему CMake. Вот и сегодня в блоге Стива Хьюстона (Steve Huston, один из разработчиков ACE) прочитал о том, что на CMake перебирается проект Apache Qpid (это OpenSource реализация протокола AMQP). Некоторое время назад на CMake, если не ошибаюсь, перебрался проект KDE. А сейчас еще ходят слухи о том, что на CMake будет перебираться Boost (что не может не радовать, т.к. я никогда не понимал, как можно пользоваться Boost.Build-ом).

Загадкой для меня является то, что CMake пользуется таким успехом. На мой вкус, build-система для кроссплатформенных C++ проектов должна:

  • давать разработчику одинаковую среду на любой платформе;
  • позволять записывать проектные файлы в виде небольших программ (с обязательной возможностью использовать if-ы, циклы, различные операции над переменными).

С этими критериями CMake справляется, на мой взгляд, не слишком. Во-первых, CMake является генератором проектных файлов. Т.е., под Linux-ом я должен сгенерировать make-файлы и запускать make. Под Visual Studio – проектные файлы и devenv. Во-вторых, CMake предоставляет свой язык программирования, который выглядит не слишком эстетично. Т.е. на троечку по каждому пункту. В отличии от, например, SCons, Rake и моего Mxx_ru. Ведь SCons, Rake, Mxx_ru сами управляют компиляцией (не требуется генерация нативных проектных файлов) и проекты записываются в виде программ на нормальных языках программирования (Python в случае SCons, Ruby в случае Rake и Mxx_ru).

Тем не менее, CMake по популярности, как мне представляется, уделывает нас всех. Вопрос: почему?

Может быть, здесь работает принцип “Worse is Better”?

Или же CMake как раз предоставляет разработчикам то, что я ошибочно считаю чем-то малозначащим? Например, я не пользуюсь IDE и, поэтому, для меня генерация проектных файлов VisualStudio – это пустой звук. Но, наверное, для значительного количества программистов это огромное достоинство CMake: они получают возможность комфортной работы в привычной для себя среде… Опять же, с проектами VisualStudio работает IncrediBuild (из коробки)… И может быть визуальная убогость языка программирования в CMake для многих вовсе не является недостатком… В общем, хотелось бы знать ответ :)

Несколько ссылок на тему build-систем:

PS. Несколько слов об Mxx_ru. В последнее время мой проект развивается “по просьбам трудящихся”. Т.е. новые возможности в нем появляются только когда меня об этом просят. Это не из-за того, что я утратил интерес к проекту, а из-за нехватки времени. Поскольку приходится разрываться между кормящими меня проектами на работе, SObjectizer и Mxx_ru (а ведь есть еще и несколько других важных для меня проектов, в частности, ObjESSty), то жертвовать приходится развитием Mxx_ru. Впрочем, как только появится достаточно стабильная версия Ruby 1.9, я обязательно портирую Mxx_ru 1.4 под нее. Ведь переход на Ruby 1.9 сулит серьезные преимущества. Во-первых, можно надеяться на увеличение скорости работы. Во-вторых, может быть под Ruby 1.9 будет гораздо проще реализовать распараллеливание компиляции больших проектов. Так что пока Mxx_ru жив! :)

PPS. Кстати, кто-нибудь знает, как можно вносить изменения в англоязычную Wikipedia? Там регистрироваться нужно, проходить какую-то процедуру одобрения внесенных на страничку изменений? А то появилось желание добавить Mxx_ru к списку build-систем.