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

суббота, 21 сентября 2024 г.

[prog.memories] Vim, Ruby, Mxx_ru -- двадцать лет в пути...

Когда-то давно, в сентябре 2009-го года здесь появилась первая заметка про мое знакомство с ViM, Ruby и рождение Mxx_ru: ViM, Ruby, Mxx_ru – пять лет в пути! Часть первая: Mxx_ru (вот вторая часть). Спустя пять лет вышло продолжение истории: Vim, Ruby, Mxx_ru -- десять лет в пути... Затем прошло еще пять лет и была написана заметка Vim, Ruby, Mxx_ru -- пятнадцать лет в пути... И вот, спустя еще пять лет, можно опубликовать очередную часть этой истории 🤓


Как бы это смешно не звучало, ViM продолжает оставаться моим основным инструментом.

При этом не могу сказать, что я чему-то еще научился за прошедшие пять лет (при этом пять лет назад знал и умел совсем немного). Продолжаю довольствоваться малым и использую ViM в минималистичном, можно сказать, базовом варианте. Под катом мой .vimrc, желающие могут посмотреть если это вдруг кому-то интересно.

В таком минимализме для меня, в общем-то, и кроется весь смысл ViM-а: я оказываюсь практически в привычном окружении на любой новой системе с минимальными телодвижениями. Это как раз то, что мне и нужно.

Про ViM могу рассказать показательную историю. В конце прошлого года подключился к проекту, в котором пока основная часть разработки ведется под Windows (с эпизодическими профилактическими сборками под Linux). Основная среда -- VisualStudio, даже сам проект был оформлен в виде .sln-файла. И, что самое важное, разработка ведется на сервере заказчика, доступ к которому дается через RDC.

Так вот, какое-то время я честно пробовал вести разработку в VisualStudio... Но сама VisualStudio оказалась тем еще тормозом, плюс у нее куча раздражающих меня настроек по умолчанию, когда она сама начинает что-то выравнивать, что-то переносить, где-то расставлять парные кавычки или скобки, которые мне не нужны, и последствия этого приходится удалять вручную... Плюс к этому добавляется не очень быстрый отклик при работе в самом RDC, т.к. я нахожусь чуть ли не в тысяче километров от сервера. В общем, набор кода в VisualStudio стал для меня тем еще испытанием и оказался крайне медленным и нервирующим процессом.

Пару месяцев терпел, но в конце-концов не выдержал. Установил ViM и начал писать код в привычном для себя окружении, а компилировался в командной строке вызывая devenv с передачей ему .sln-файла и нужных параметров. Можно сказать, вернулся в родной мир.

Так что ViM-ом продолжаю с удовольствием пользоваться. А посему могу смело сказать: 20 years with Vim and still learning :) And happy Vimmming!


Ruby практически не использую в последнее время. Нет необходимости. Уж не знаю хорошо ли это или нет, но вот не нужен он пока. Из-за чего уже основательно подзабыл этот отличный динамически-типизированный язык.

Пару лет назад в одном из проектов довелось столкнуться с Python-ом. Мне не нужно было на Python-е программировать самому, требовалось встроить его в C++ приложение, но все равно пришлось почитать что это такое и погрузится в некоторые его особенности. Порадовался тому, что в свое время выбрал Ruby, а не Python. Как по мне, так Ruby делали как инструмент для программистов, тогда как Python -- для <censored> не умеющих программировать, мягко говоря. И, судя по тому, какое распространение Python получил за прошедшие годы, умеющих программировать больше не стало 😏


Mxx_ru продолжаю использовать при разработке SObjectizer и json_dto. И кайфую от этого. Но это прекрасное время уже скоро закончится... 🥹

В прошлом году в RESTinio-0.7 мы уже полностью перешли с Mxx_ru на CMake.

Полагаю, что в 2025-ом или в 2026-ом, при переводе SObjectizer-а на C++20 (а может быть и сразу на C++23) мы также откажемся от Mxx_ru в пользу CMake. А там и очередь json_dto подойдет.

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

Тем более, что комитет по стандартизации C++ в очередной раз поднасрал C++никам внедрив в язык настолько говенную мудрёную систему модулей, что разработчики компиляторов все никак не могут допилить ее полноценную поддержку. Но допилят рано или поздно. А когда допилят, то окажется, что все наколеночные системы сборки (вроде нашей Mxx_ru) превратятся в тыкву: либо обновляйся и добавляй поддержку того, что придумали сумрачные гении из комитета, либо переходи на что-то другое.

Возможностей сделать Mxx_ru-2.0 с поддержкой C++ных модулей у меня нет и вряд ли найдутся, сам я не становлюсь моложе, запаса сил все меньше. Поэтому Mxx_ru доживает свои последние годы. Се ля ви.


Наверное, как-то грустно получилось. Но, с другой стороны, отрадно, что сама по себе история продлилась целых двадцать лет. Так что все хорошо, нет повода расстраиваться. Даже интересно, смоглу ли написать что-то на эту тему спустя еще пять лет. Будем посмотреть 😉

пятница, 13 сентября 2019 г.

[prog.memories] Vim, Ruby, Mxx_ru -- пятнадцать лет в пути...

Когда-то давно, в сентябре 2009-го года здесь появилась первая заметка про мое знакомство с ViM, Ruby и появление Mxx_ru: ViM, Ruby, Mxx_ru – пять лет в пути! Часть первая: Mxx_ru (вот вторая часть). Спустя пять лет вышло продолжение истории: Vim, Ruby, Mxx_ru -- десять лет в пути... И вот, спустя еще пять лет, можно написать очередную часть этой истории.


Итак, ViM. Все еще мой основной редактор для написания кода. Пользуюсь им и под Windows, и под Linux, и под FreeBSD. Под Linux-ом, кстати говоря, ViM как-то заметно шустрее работает.

Назвать себя продвинутым пользователем ViM-а не могу, знаю и применяю лишь некий базовый набор команд. Подозреваю, что лет 10 назад я знал про ViM гораздо больше. Но многие знания были утеряны за время менеджерства. Ну и сейчас программирование занимает далеко не 100% моего времени, так что надобности сильно погружаться в дебри ViM-а нет.

Тем не менее, с полной уверенностью могу сказать сейчас про себя: 15 years with Vim and steel learning :) And happy Vimmming!


Раздел второй, Ruby. В последний раз что-то более-менее серьезное писал на Ruby когда в начале 2016-го года добавлял в Mxx_ru поддержку работы с зависимостями (под условным названием MxxRu::externals). С тех пор пишу разве что небольшие одноразовые программки на выброс.

Оглядываясь назад могу лишь порадоваться тому, что у меня был период увлечения Ruby. Динамически-типизированные языки, особенно такие приятные в использовании, как Ruby -- это очень интересная и отдельная тема для разговора. Тот случай, когда зачастую программирование вновь превращается в удовольствие. Но только если это в терапевтических дозах. На небольших проектах, которые делаются небольшими командами. Сопровождать и развивать большую и старую кодовую базу на динамически-типизированном языке, пусть даже таком приятном, как Ruby... Да ну нафиг такое щасте с большой буквы Щ :)))


Раздел третий, Mxx_ru. Чем больше приходится иметь дел с CMake, тем больше радуюсь, что у меня есть Mxx_ru. Но, боюсь, радоваться мне остается недолго. В C++20 приняли какую-то (пока) неведомую для меня хрень в виде хитровывернутых модулей. Ну оно-то понятно, как можно в C++ добавить что-то понятное, простое и удобное? Очевидно, что никак. Такого не бывает, все должно быть через боль и страдания, это же C++...

Так вот, когда поддержка модулей появится в основных мейнстримовых компиляторах (т.е. VC++, GCC, clang), то придется делать выбор: либо допиливать Mxx_ru до поддержки C++ных модулей, либо полностью уходить с Mxx_ru.

И если год-два назад я был уверен, что серьезно ничего менять в Mxx_ru не буду, то теперь, после регулярного траха с CMake я уже не так уверен. Ибо выбирая между CMake и переделкой Mxx_ru мне уже не кажется, что разработка Mxx_ru-2.0 -- это рисковано, долго и дорого.

Так что если не найдется какая-то гораздо более вменяемая альтернатива CMake (в виде какого-нибудь Meson-а или GN), то вполне возможен сценарий появления на свет Mxx_ru-2.0.


Ну вот как-то так. 15 лет развития какой-то истории -- это совсем немало. Точно могу сказать, что затевая Mxx_ru в августе 2004-го года я вообще не надеялся на то, что этот инструмент проживет столько лет. Теперь уже и самому стало очень интересно, будет ли через пять лет продолжение. И если будет, то какое именно?

Жизнь покажет.

пятница, 1 июня 2018 г.

[prog.c++] Попытка подружить "модульный" Boost с MxxRu::externals

Начал чесать репу на тему создания такого mchain-а или mbox-а для SObjectizer-а, который бы позволил двум SObjectizer-приложениям на одной ноде взаимодействовать друг с другом через разделяемую память. Беглый поиск по Интернету показал, что выбор инструментов для этой задачи сравнительно небольшой: либо придется делать свой собственный велосипед, либо же нужно брать что-то из Boost, ACE, POCO или чего-то сравнимого по размеру.

Писать свой лисапед не захотелось, тем более, что сперва нужно сделать какой-то прототип нового mchain-а, ибо на данный момент реализация такого mchain-а выглядит как сплошное белое пятно. Хочется без лишних проволочек начать работать над прототипом, а уже потом, когда прототип заработает, решать, что же делать дальше.

Решил попробовать Boost.Interprocess. Но т.к. с "большим" Boost-ом иметь дело не хочется, то попробовал подтащить в небольшой демо-проектик Boost.Interprocess и все его зависимости из "модульного" Boost-а, который нынче доступен на github-е.

Методом проб и ошибок это удалось сделать (в очередной раз скажу, что Boost в виде большой говнопомойки не нужен и должен быть разрушен). Результат можно увидеть в этом репозитории. Ниже чуть-чуть прокомментирую то, что получилось.

четверг, 10 мая 2018 г.

[prog] MxxRu обновился до версии 1.6.14.5

Сегодня выкатили очередное обновление для нашей системы сборки MxxRu (она же Mxx_ru). В версии 1.6.14.5 был исправлен недочет в поведении анализатора C++зависимостей, из-за которого происходило зацикливание, если в компилирующемся проекте активно использовались конструкции вида:

#include "../details/some_file.h"

Например, мы поймали эти проблемы при попытке использования spdlog-0.16.3, в котором как раз такие include и используются.

Обновится до версии 1.6.14.5 можно посредством команды:

gem update Mxx_ru

В каких-то Linux-ах это нужно будет делать с правами администратора, например, в Ubuntu:

sudo gem update Mxx_ru

среда, 7 сентября 2016 г.

[prog] Mxx_ru-1.6.13 с поддержкой clang под Windows

Сделал очередной релиз своей кроссплатформенной системы сборки C/C++ проектов: Mxx_ru версии 1.6.13.

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

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

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

В этой версии добавлена поддержка тулсета clang_msvc. Недавно вышедший llvm-3.9.0 у меня впервые нормально заработал под Windows в связке с Visual C++ 14.0 (update3). Т.е. транслятор от llvm, а все заголовочные файлы, библиотеки и линкер -- от VC++.


Получается, что clang сейчас поддерживается в нескольких видах: под Unix-ами и под Windows поверх VC++. Видимо, со временем надо будет в Mxx_ru добавить для clang-а что-то вроде gcc_port. В версии 1.6.13 ничего подобного пока нет. Сначала поднакопим опыт, а дальше будет видно.

четверг, 4 августа 2016 г.

[prog] Демонстрация поведения разных ObjPlacement в MxxRu

В предыдущем посте написал много слов о том, что такое ObjPlacement и какие ObjPlacement как себя ведут. Похоже, проще один раз показать :)

Итак, пусть у нас есть вот такая файловая структура:

.
├── build.rb
└── demo
    ├── prj.rb
    └── src
        └── some_rather_long_path
            └── to_source
                └── file
                    └── main.cpp

Где main.cpp -- это классический hello_world:

#include <iostream>

int main() {
   std::cout << "Hello, world" << std::endl;
}

Проектный файл для этого hello_world имеет простейший вид (файл demo/prj.rb):

gem 'Mxx_ru'
require 'mxx_ru/cpp'

MxxRu::Cpp::exe_target {
  target 'demo.app'
  cpp_source 'src/some_rather_long_path/to_source/file/main.cpp'
}

Ну и в build.rb пока ничего интересного нет вообще:

#!/usr/bin/ruby
gem 'Mxx_ru''>= 1.6.12'
require 'mxx_ru/cpp'

MxxRu::Cpp::composite_target( MxxRu::BUILD_ROOT ) {
  required_prj 'demo/prj.rb'
}

Запускаем сборку ./build.rb --mxx-cpp-release и получаем следующее содержимое:

[prog] Mxx_ru-1.6.12 с еще одним ObjPlacement из коробки

Сделал очередной релиз своей кроссплатформенной системы сборки C/C++ проектов: Mxx_ru версии 1.6.12

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

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

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

Единственное, но важное, обновление версии 1.6.12 по сравнению с предшествующей версией 1.6.11 -- это появление класса PrjAwareRuntimeSubdirObjPlacement. Этот ObjPlacement позволяет получить возможность сборки одних и тех же исходников в lib или в so/dll прямо "из коробки".

Для того, чтобы пояснить нужность PrjAwareRuntimeSubdirObjPlacement требуется сперва объяснить роль ObjPlacement в MxxRu...

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

[prog] Не могу не поделиться удовольствием от использования MxxRu::externals

Совсем маленький свежий пример. Было небольшое описание внешних зависимостей для тестового проектика:

MxxRu::svn_externals :so5 do |e|
  e.url 'http://svn.code.sf.net/p/sobjectizer/repo/tags/so_5/5.5.16'
  e.option '-q'
  e.option '--native-eol''LF'

  e.map_dir 'dev/so_5' => 'dev'
end

MxxRu::svn_externals :timertt do |e|
  e.url 'http://svn.code.sf.net/p/sobjectizer/repo/tags/timertt/1.1.1'
  e.option '-q'
  e.option '--native-eol''LF'

  e.map_dir 'dev/timertt' => 'dev'
end

MxxRu::arch_externals :boost_process do |e|
  e.url 'http://www.highscore.de/boost/process0.5/process.zip'

  e.map_dir 'boost' => 'dev'
end

MxxRu::hg_externals :boost_process_mxxru do |e|
  e.url 'https://bitbucket.org/sobjectizerteam/boost_process_mxxru-0.1'
  e.map_dir 'dev/boost_process_mxxru' => 'dev'
end

Понадобилось добавить в проект еще одну зависимость -- библиотеку procxx. Эта малюсенькая header-only библиотека, которая живет на GitHub-е, имеет только одну ветку master и не имеет на данный момент ни одного релиза. Добавляю всего несколько строк в externals.rb и получаю зависимость от конкретного коммита в репозитории procxx (что позволяет не боятся сюрпризов, если в последующих коммитах появятся какие-нибудь ломающие совместимость изменения):

MxxRu::git_externals :procxx do |e|
  e.url 'https://github.com/skystrife/procxx'
  e.commit 'dfd9818'
  e.map_file 'include/process.h' => 'dev/procxx/*'
end

Запускаю mxxruexternals...

понедельник, 25 апреля 2016 г.

[prog] Mxx_ru-1.6.11 с первой версией поддержки CMake-проектов

Mxx_ru обновился до версии 1.6.11

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

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

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

Из мелочей: в данной версии появились новые шаблоны externals и ext-cmake-prj для mxxrugen. А так же новый тип obj_placement-а под именем ToolsetRuntimeSubdirObjPlacement, который создает имена подкаталогов с результатами компиляции вида vc14_0_19_00_23918_x64 и gccmingw_5_3_0__x86_64_w64_mingw32.

А из главного в этой версии реализована возможность использования проектов с CMake-вскими проектными файлами в рамках контролируемой Mxx_ru сборки. Как это может выглядеть покажу на примере подключения исходников библиотеки soci в Mxx_ru-шный проект.

пятница, 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 выпускать :)

вторник, 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 теперь может самостоятельно обнаруживать, что изменилось в файле описаний внешних зависимостей и предпринимать соответствующие действия. Подробнее под катом.

четверг, 31 марта 2016 г.

[prog] Mxx_ru 1.6.9

Mxx_ru обновился до версии 1.6.9. В этой версии реализована поддержка звездочек в именах, указываемых в map/map_dir и map_file (подробнее в предыдущем посте).

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

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

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

PS. Документация пока не обновлялась из-за отсутствия времени :(

вторник, 29 марта 2016 г.

[prog] По следам опыта с Mxx_ru-1.6.8 и перед релизом Mxx_ru-1.6.9

Накопился некоторый, пусть и небольшой, опыт работы с MxxRu::externals из Mxx_ru-1.6.8. Хорошая новость: externals-ы таки работают. А вот плохих новостей нет :)

Однако, уже очевидно, что некоторые доработки нужны.

Прежде всего, оказалось желательно разрешит переименования исходного каталога в команде map_dir. Например, был каталог some-prj/src/lib, захотели, чтобы он скопировался просто в some-prj/src. Версия 1.6.8 это не позволяла делать.

Так же несколько утомляет необходимость писать имя копируемого файла и в источнике, и в приемнике для map_file. Т.е., когда несколько раз напишешь что-то вроде e.map_file 'prj/src/h/config.h' => 'h/config.h', то это надоедает.

В связи с этим сделаны наметки версии 1.6.9, в которой реализованы решения для двух вышеуказанных случаев:

MxxRu::arch_externals :libmosquitto do |e|
  e.url 'http://mosquitto.org/files/source/mosquitto-1.4.8.tar.gz'

  e.map_dir 'lib/*' => 'dev/libmosquitto/src'
  e.map_file 'config.h' => 'dev/libmosquitto/*'
end

Т.е. если в параметре src для map_dir последним элементом является звездочка, то считается, что в dst задано новое имя для исходного каталога. В данном примере каталог lib копируется в каталог dev/libmosquitto под именем src.

Если в параметре dst для map_file последним элементом является звездочка, то считается, что имя файла при копировании должно сохраниться. Т.е. в примере выше файл config.h будет скопирован в файл dev/libmosquitto/config.h.

Лично мне пока оба решения нравятся. Вроде бы просто и понятно, плюс совместимость не нарушается. Но это мое мнение. Интересно и другие мнения послушать. Если есть противопоказания, то проще сейчас все переделать, а не после того, как версия 1.6.9 будет зафиксирована.

В общем, если не будет никаких возражений, то через два-три дня версия 1.6.9 с этими двумя нововведениями выйдет в свет.

Но есть так же еще несколько соображений, которые имеет смысл обдумать и, может быть, реализовать в последующих версиях...

среда, 9 марта 2016 г.

[prog] Mxx_ru 1.6.8

Вышла версия 1.6.8 инструмента Mxx_ru с первой полной реализацией т.н. externals. Теперь внешние проекты можно забирать из репозиториев Git, Hg, Subversion, а так же в виде tar, zip и 7z архивов.

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

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

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

PDF-ку с документацией буду обновлять. Если все пойдет нормально, то надеюсь выложить ее в начале следующей недели. Пока же информацию о возможностях версии 1.6.8 можно найти в блоге и G+ (запись номер раз, запись номер два, запись номер три, плюс дополнительная информация под катом).

понедельник, 7 марта 2016 г.

[prog] В предверии Mxx_ru 1.6.8: пример того, что умеет MxxRu::externals

Думаю, что вот этим уже можно хвастаться:

gem 'Mxx_ru''>= 1.6.8'
require 'mxx_ru/externals'

MxxRu::arch_externals :asio do |e|
  e.url 'https://github.com/chriskohlhoff/asio/archive/asio-1-11-0.tar.gz' 
  e.sha1 '1be2489015a1e1c7b8666a5a803d984cdec4a12b'

  e.map_dir 'asio/include' => 'sources/asio'
  e.map_file 'asio/src/asio.cpp' => 'sources/asio/src/asio.cpp'
  e.map_file 'asio/src/asio_ssl.cpp' => 'sources/asio/src/asio_ssl.cpp'
end

MxxRu::git_externals :spdlog do |e|
  e.url 'https://github.com/gabime/spdlog.git'
  e.commit 'c6f8f1d'
  e.map 'include/spdlog' => 'sources'
end

MxxRu::arch_externals :eigen do |e|
  e.url 'https://bitbucket.org/eigen/eigen/get/3.2.5.tar.bz2'
  e.sha1 'aa4667f0b134f5688c5dff5f03335d9a19aa9b3d' 

  e.map 'Eigen' => 'sources'
end

MxxRu::arch_externals :so_5 do |e|
  e.url 'https://sourceforge.net/projects/sobjectizer/files/sobjectizer/SObjectizer%20Core%20v.5.5/so-5.5.15.2.zip'
  e.sha1 'd2a4c5e262d8b8ff023f18d93bd742d0b0da4aa1'
 
  e.map 'dev/so_5' => 'sources'

  e.unpacker_option '-q'
end

Что здесь происходит?

пятница, 4 марта 2016 г.

[prog] Mxx_ru 1.6.7

Вышла версия 1.6.7 инструмента Mxx_ru с начальной поддержкой т.н. externals. Теперь в Mxx_ru есть средства для выкачивания внешних зависимостей из Git/Hg/Svn и установки частей этих зависимостей в нужные подкаталоги. Пока внешние зависимости берутся только из репозиториев Git/Hg/Svn. Поддержка закачки тарболлов/архивов будет добавлена в следующей версии. Надеюсь, получится выкатить ее достаточно быстро.

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

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

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

PDF-ку с документацией пока не обновлял. Сделаю это уже после выпуска версии с поддержкой тарболлов. Посему единственная имеющаяся в наличии документация собрана в этом посте под катом.

Итак, что такое MxxRu::externals и как с ними бороться?

четверг, 3 марта 2016 г.

[prog] Наметки самодельной альтернативы CMake-овскому ExternalProject_Add

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

ExternalProject_add(so_5_prj
  SVN_REPOSITORY http://svn.code.sf.net/p/sobjectizer/repo/tags/so_5/5.5.15.2/dev
  CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
  INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
)

Хочется писать на Ruby как-то вот так:

MxxRu::svn_externals :so_5 do |ext|
   ext.url 'http://svn.code.sf.net/p/sobjectizer/repo/tags/so_5/5.5.15.2' 
   ext.map 'dev/so_5' => 'dev'
end

Ну или даже вот так:

MxxRu::svn_externals :so_5 do |ext|
   ext.url 'http://svn.code.sf.net/p/sobjectizer/repo/tags/so_5/5.5.15.2' 
   ext.option '-q'
   ext.option '--native-eol''LF'
   ext.map 'dev/so_5' => 'dev'
   ext.map 'dev/test/so_5' => 'test'
   ext.map 'dev/samples/so_5' => 'samples'
end

На данный момент уже вполне себе дышит работа с Git, Hg и Svn. Нужно еще подумать на счет реализации дополнительных опций, вроде :clober и :reload. И можно будет релизить новую версию Mxx_ru с поддержкой такого вот подхода к получению зависимостей из внешних источников. Ну а потом на очереди будет загрузка (http/https, ftp) архивов (tar.gz, tar.bz2, tar.xz, zip, 7z). Там, глядишь, и без пакетного менеджера для C++ можно будет прожить еще какое-то время :)

суббота, 1 августа 2015 г.

[prog] Mxx_ru 1.6.6

Mxx_ru обновился до версии 1.6.6. Добавлена поддержка Visual C++ v.14.0 (из состава Visual Studio 2015), что означает появление тулсета vc14. Этот тулсет может быть выставлен вручную в переменной среды MXX_RU_CPP_TOOLSET. Так же тулсет vc14 может быть определен автоматически есть переменная среды MXX_RU_CPP_TOOLSET не задана.

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

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

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

PS. Некоторая нерасторопность с реализацией поддержки vc14 была вызвана проблемами сайта SF.net. Приношу свои извинения.

пятница, 10 апреля 2015 г.

[prog] Mxx_ru 1.6.5

Mxx_ru обновился до версии 1.6.5. Это простой баг-фикс релиз, исправлена ошибка с выставлением ключика "-std=c++14" для clang и GCC.

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