четверг, 2 сентября 2010 г.

[prog.thoughts] Как лучше оформлять библиотеки для SObjectizer?

Не очень приятно раскрывать карты раньше времени, но есть важный вопрос, на который нужно найти хороший ответ.

В результате расширения моей команды весной этого года (части первая и вторая этой эпопеи) появились ресурсы на продолжение работ по SObjectizer со товарищи библиотеками :) Что привело к тому, что у нас разработаны новые версии SObjectizer-библиотек, которые мы хотим опубликовать на SourceForge. Но!

Лично мне кажется, что принятая сейчас форма публикации SObjectizer-библиотек не удобна для потенциальных пользователей. Например, если кто-то захочет использовать so_sysconf и so_alt_channel, то ему нужно будет скачать два архива (плюс еще архив с самим sobjectizer-ом), взять оттуда нужные подкаталоги, скопировать их куда-то к себе и совместить должным образом с каталогом SObjectizer (чуть подробнее эта процедура описана здесь).

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

Сейчас я думаю распространять и сам SObjectizer, и все опубликованные библиотеки одним архивом, в котором есть все (по аналогии с тем, как это сделано в Boost и ACE). Например, архив so_bunch_20100910.tar.bz2, в котором имеется следующая структура:

so_bunch_20100910/
`-dev/
  `-ace/
  `-ace_lib_distrib/
  `-auto_ptr_3/
  `-cls_3/
  `-cpp_util_2/
  `-gemont_1/
  `-lib/	
  `-oess_1/
  `-smart_ref_3/
  `-so_4/
  `-so_alt_channel_2/
  `-so_log_1/
  `-so_sysconf_3/
  `-so_sysconf_3_meta_action/
  `-so_sysconf_breakflag_handler/
  `-so_sysconf_channel_common/
  `-so_sysconf_daemon/
  `-so_sysconf_gemont_2/
  `-so_sysconf_ichannel/
  `-so_sysconf_log_2/
  `-so_sysconf_ntservice/
  `-so_sysconf_ochannel/
  `-so_sysconf_process/
  `-test/
  `-samples/

Мне кажется, что так будет проще взять архив, распаковать его куда-нибудь, скомпилировать, протестировать. А потом, при необходимости, прописать к нему пути в INCLUDE и LIB, или же включить в собственный проект.

Так же, я думаю, мы попробуем выпустить вариант со скомпилированной под win32 версией (под MSVS 2008). Как минимум, в Release-варианте. Может быть еще и в Debug-варианте.

Вот такие идеи. Собственно вопрос – нужно ли всем этим заморачиваться? Или есть какой-то другой способ?

4 комментария:

night beast комментирует...

не совсем знаком SObjectizer, так что извини, если где не в тему :)

субъективное мнение:
один архив сделать конечно нужно, но и возможность скачать по отдельности тоже должна быть, а не как в бусте( нужен тебе один shered_prt -- выпиливай как хочешь)
структуру предлагаю такую:
ace.zip
pub.zip
src/
-auto_ptr
-cpp_util
-smart_ref
test/
samples/
...
so.zip
src/
-so_...
test/
samples/
so-tools.zip
src/
-gemont
-so_alt_channel
-so_sysconf
test/
samples/

eao197 комментирует...

@night beast: спасибо!

Сейчас мы сможем только сделать один большой архив и по одному архиву на каждый подпроект. На большее ресурсов не хватит.

А со временем, если повезет, замутим пакетный менеджер (что он должен делать уже, к счастью, понятно). Тогда будет удобнее.

Stan комментирует...

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

Буквально на днях узнал, что в Qt есть классы для взаимодействия с различными БД. Очевидно, что задача взаимодействия с БД не является специфичной для Qt, но вроде бы никто не задумывается о том, чтобы поставлять данный набор классов отдельно от Qt. Тоесть либо используем Qt и все классы, которые в ней есть, либо пользуемся чем-то другим.

eao197 комментирует...

2Stan: спасибо за комментарий.

В отличии от Qt или wxWidgets у нас не платформа. Скорее библиотека для решения частной задачи. Плюс набор небольших инструментов, которые могли бы пригодиться при разработке server-side приложений.