Путевка в жизнь для Open Source-проекта: распространение
Содержание:
1. Введение;
2. Распространение (Вы читаете данный раздел);
3. Перевод.
Одно из условий, способствующих распространению вашей программы, - это написание толковых правил сборки под какую-нибудь систему сборки вроде autotools, scons, cmake или qmake. Есть гениальные (говорю без иронии) программисты, которые снабдят исходник готовым Makefile и в таком виде выкладывают в сеть, а вы уж пляшите с бубном, гадайте в дымовой яме. Готовый Makefile допустим лишь, ежели ваша программа - «остров», которому не нужно ничего извне, всё своё она несет с собой, не зависит от внешних библиотек, переменных окружения и тому подобного. Иначе же извольте сочинять правила. Старейшая из популярных систем сборки - GNU build system, она же autotools. С нею вы сталкиваетесь, когда видите в исходнике чудо-скрипт configure, столь огромный, что зачастую он больше самого исходника. Никто не пишет configure вручную - для этого создаются файлы правил, на основе коих - скрипт autogen.sh. Он в свою очередь вызывает ряд других утилит, обрабатывает правила и на их основе создает configure, результатом запуска которого будет файл Makefile. Далее - дело техники: команда make и ожидание окончания сборки.
Но что же это за правила? Все очень просто: вы должны расписать для системы сборки, какие файлы у вас являются исходниками, какие - файлами перевода, какие библиотеки нужны обязательно (а без каких можно обойтись), в какие каталоги надо устанавливать заданные файлы при выполнении команды make install. У разных систем сборки разные макроязыки правил. Для некоторых программ пишутся правила под несколько систем сборки: допустим, autotools и cmake, или cmake и qmake. Какую систему сборки поддерживать - ваше дело. Очевидно, что qmake заточена на Qt, а вот autotools универсальна. KDE использует cmake, отказавшись от autotools, - факт, указывающий на зрелость cmake. Вот документация на русском по cmake - https://techbase.kde.org/Development/Tutorials/CMake_(ru), а вот ссылка о том, как подружить cmake и Qt: http://qtnode.net/wiki/ Qt with cmake.
Существует еще написанная на Python система сборки Scons. Файлы правил для неё - скрипты на Python. Например, для «видимости» libxml в проекте надо писать такое:
Scons используется, например, для сборки Doom 3 и для цифровой студии звукозаписи Ardour. У каждой системы сборки есть плюсы и минусы, autotools порицают более других, но и распространена она больше. При хорошо прописанных правилах и наличии у пользователя всех необходимых для сборки библиотек сборка сводится к традиционному выполнению «./configure && make && make install». Мне кажется, что во многих случаях недовольство autotools вызвано нежеланием программистов изучить работу этих autotools, поэтому, не разобравшись, программисты начинают поиски других решений. Речь не идет, конечно, о переходе с autotools на что-то другое большого проекта вроде KDE. Но в целом autotools не так плоха и страшна, как её малюют. И, кстати, очень гибкая.
Исходники лучше распространять в «тарболлах» формата имя-программы-версия.tar.gz или tar.bz2. Собрать все нужные для такого тарболла файлы в одном каталоге с готовым именем можно (в случае, если поддерживается цель сборки dist) командой make dist - на выходе вы получаете каталог с именем вида myprogram-1.2.3. Этот каталог удобно запаковать в архив - я всегда это делаю через контекстное меню в Midnight Commander (по [F2]). Перед упаковкой удалите из исходника файлы *.gmo, moc_*, qrc_*, если таковые существуют - всё равно при сборке у пользователя они будут пересозданы, и таскать их в тарболле нет нужды.
Указание версии в названии тарболла - хороший тон. Многие скрипты, используемые сборщиками пакетов, подразумевают наличие версии в имени тарболла. Вот так мы плавно перешли к другой теме - пакетам. Есть дистрибутивы Linux, где сборку можно удобно автоматизировать каким-нибудь скриптом. А есть дистрибутивы, где внутренние правила способствуют возникновению головной боли, и к «upstream-версии» (так сборщики пакетов называют авторский исходник) добавляются всякие патчи, а зачастую некая правка вносится даже вручную. Обычно сборку пакетов берут на себя энтузиасты. Конечно, вы тоже можете собирать пакеты, и даже под несколько дистрибутивов, ибо виртуальные машины - великая сила. Однако на практике на возню с пакетами просто не хватает времени.
Если ваша программа компилируется и под Windows, то на благоприятное впечатление от продукта повлияет наличие программы-установщика. Советую для его создания использовать NSIS (http://nsis.sourceforge.net) - тоже, кстати, свободное ПО. Установщики «от NSIS» хорошо знакомы по таким программам, как Winamp, Reaper. Сначала разработчиком NSIS был легендарный Джастин Франкел, но потом он отдал проект сообществу. Замечу, что, если вы свяжитесь с NSIS, то код скрипта для создания установщика будет самым сложным кодом в вашем проекте. Кстати, чтобы установщик правильно работал в среде Vista, добавьте в NSIS-скрипт строку:
С выпуском новой версии программы хорошо бы донести эту благую весть миру. Первым делом сообщите через рассылку, если таковая у вас есть. Можно сделать сообщество в ЖЖ или группу «ВКонтакте». Очень советую завести учетную запись на freshmeat.net и отражать там каждый новый выпуск. Freshmeat - это не хостинг, а просто каталог ПО с удобным интерфейсом. Огромный плюс - новости с Freshmeat распространяются по множеству других сайтов.
Есть также специфические каталоги для программ, основанных на Qt, GTK, GNOME и KDE:
- www.qt-apps.org (Qt);
- www.gtk-apps.org (GTK);
- gnomefiles.org (GTK/GNOME);
- www.kde-apps.org (Qt/KDE).
Отечественные каталоги полезны для раскрутки Windows-версии вашей программы. Несколько смущает факт, что создатели русских будто бы не знают о свободном ПО, о лицензиях, из-за чего ПО с открытым кодом и свободное ПО приходится размещать как «бесплатное» или «freeware».
1. Введение;
2.
3. Перевод.
Одно из условий, способствующих распространению вашей программы, - это написание толковых правил сборки под какую-нибудь систему сборки вроде autotools, scons, cmake или qmake. Есть гениальные (говорю без иронии) программисты, которые снабдят исходник готовым Makefile и в таком виде выкладывают в сеть, а вы уж пляшите с бубном, гадайте в дымовой яме. Готовый Makefile допустим лишь, ежели ваша программа - «остров», которому не нужно ничего извне, всё своё она несет с собой, не зависит от внешних библиотек, переменных окружения и тому подобного. Иначе же извольте сочинять правила. Старейшая из популярных систем сборки - GNU build system, она же autotools. С нею вы сталкиваетесь, когда видите в исходнике чудо-скрипт configure, столь огромный, что зачастую он больше самого исходника. Никто не пишет configure вручную - для этого создаются файлы правил, на основе коих - скрипт autogen.sh. Он в свою очередь вызывает ряд других утилит, обрабатывает правила и на их основе создает configure, результатом запуска которого будет файл Makefile. Далее - дело техники: команда make и ожидание окончания сборки.
Но что же это за правила? Все очень просто: вы должны расписать для системы сборки, какие файлы у вас являются исходниками, какие - файлами перевода, какие библиотеки нужны обязательно (а без каких можно обойтись), в какие каталоги надо устанавливать заданные файлы при выполнении команды make install. У разных систем сборки разные макроязыки правил. Для некоторых программ пишутся правила под несколько систем сборки: допустим, autotools и cmake, или cmake и qmake. Какую систему сборки поддерживать - ваше дело. Очевидно, что qmake заточена на Qt, а вот autotools универсальна. KDE использует cmake, отказавшись от autotools, - факт, указывающий на зрелость cmake. Вот документация на русском по cmake - https://techbase.kde.org/Development/Tutorials/CMake_(ru), а вот ссылка о том, как подружить cmake и Qt: http://qtnode.net/wiki/ Qt with cmake.
Существует еще написанная на Python система сборки Scons. Файлы правил для неё - скрипты на Python. Например, для «видимости» libxml в проекте надо писать такое:
env.ParseConfig ('pkg-config —cflags —libs libxml')
Scons используется, например, для сборки Doom 3 и для цифровой студии звукозаписи Ardour. У каждой системы сборки есть плюсы и минусы, autotools порицают более других, но и распространена она больше. При хорошо прописанных правилах и наличии у пользователя всех необходимых для сборки библиотек сборка сводится к традиционному выполнению «./configure && make && make install». Мне кажется, что во многих случаях недовольство autotools вызвано нежеланием программистов изучить работу этих autotools, поэтому, не разобравшись, программисты начинают поиски других решений. Речь не идет, конечно, о переходе с autotools на что-то другое большого проекта вроде KDE. Но в целом autotools не так плоха и страшна, как её малюют. И, кстати, очень гибкая.
Исходники лучше распространять в «тарболлах» формата имя-программы-версия.tar.gz или tar.bz2. Собрать все нужные для такого тарболла файлы в одном каталоге с готовым именем можно (в случае, если поддерживается цель сборки dist) командой make dist - на выходе вы получаете каталог с именем вида myprogram-1.2.3. Этот каталог удобно запаковать в архив - я всегда это делаю через контекстное меню в Midnight Commander (по [F2]). Перед упаковкой удалите из исходника файлы *.gmo, moc_*, qrc_*, если таковые существуют - всё равно при сборке у пользователя они будут пересозданы, и таскать их в тарболле нет нужды.
Указание версии в названии тарболла - хороший тон. Многие скрипты, используемые сборщиками пакетов, подразумевают наличие версии в имени тарболла. Вот так мы плавно перешли к другой теме - пакетам. Есть дистрибутивы Linux, где сборку можно удобно автоматизировать каким-нибудь скриптом. А есть дистрибутивы, где внутренние правила способствуют возникновению головной боли, и к «upstream-версии» (так сборщики пакетов называют авторский исходник) добавляются всякие патчи, а зачастую некая правка вносится даже вручную. Обычно сборку пакетов берут на себя энтузиасты. Конечно, вы тоже можете собирать пакеты, и даже под несколько дистрибутивов, ибо виртуальные машины - великая сила. Однако на практике на возню с пакетами просто не хватает времени.
Если ваша программа компилируется и под Windows, то на благоприятное впечатление от продукта повлияет наличие программы-установщика. Советую для его создания использовать NSIS (http://nsis.sourceforge.net) - тоже, кстати, свободное ПО. Установщики «от NSIS» хорошо знакомы по таким программам, как Winamp, Reaper. Сначала разработчиком NSIS был легендарный Джастин Франкел, но потом он отдал проект сообществу. Замечу, что, если вы свяжитесь с NSIS, то код скрипта для создания установщика будет самым сложным кодом в вашем проекте. Кстати, чтобы установщик правильно работал в среде Vista, добавьте в NSIS-скрипт строку:
RequestExecutionLevel user
С выпуском новой версии программы хорошо бы донести эту благую весть миру. Первым делом сообщите через рассылку, если таковая у вас есть. Можно сделать сообщество в ЖЖ или группу «ВКонтакте». Очень советую завести учетную запись на freshmeat.net и отражать там каждый новый выпуск. Freshmeat - это не хостинг, а просто каталог ПО с удобным интерфейсом. Огромный плюс - новости с Freshmeat распространяются по множеству других сайтов.
Есть также специфические каталоги для программ, основанных на Qt, GTK, GNOME и KDE:
- www.qt-apps.org (Qt);
- www.gtk-apps.org (GTK);
- gnomefiles.org (GTK/GNOME);
- www.kde-apps.org (Qt/KDE).
Отечественные каталоги полезны для раскрутки Windows-версии вашей программы. Несколько смущает факт, что создатели русских будто бы не знают о свободном ПО, о лицензиях, из-за чего ПО с открытым кодом и свободное ПО приходится размещать как «бесплатное» или «freeware».
