Не очень приятно раскрывать карты раньше времени, но есть важный вопрос, на который нужно найти хороший ответ.
В результате расширения моей команды весной этого года (части первая и вторая этой эпопеи) появились ресурсы на продолжение работ по 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 комментария:
не совсем знаком 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/
@night beast: спасибо!
Сейчас мы сможем только сделать один большой архив и по одному архиву на каждый подпроект. На большее ресурсов не хватит.
А со временем, если повезет, замутим пакетный менеджер (что он должен делать уже, к счастью, понятно). Тогда будет удобнее.
Мне кажется, что необходимо определиться с тем, что собственно поставляется - набор библиотек, для упрощения решения некоторых задач на C++ или платформа / библиотека для решения некоторого класса прикладных задач.
Буквально на днях узнал, что в Qt есть классы для взаимодействия с различными БД. Очевидно, что задача взаимодействия с БД не является специфичной для Qt, но вроде бы никто не задумывается о том, чтобы поставлять данный набор классов отдельно от Qt. Тоесть либо используем Qt и все классы, которые в ней есть, либо пользуемся чем-то другим.
2Stan: спасибо за комментарий.
В отличии от Qt или wxWidgets у нас не платформа. Скорее библиотека для решения частной задачи. Плюс набор небольших инструментов, которые могли бы пригодиться при разработке server-side приложений.
Отправить комментарий