[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-варианте.

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