Книжка по о том как сделать хороший, годный source.tar.gz

А вот как приготовить пакет *.tar.gz как у больших дядек — так чтобы все, последовательно и сразу — не могу найти...

http://www.gnu.org/software/hello/

Короче, программирование в традициях сообщества.

«Традиции сообщества» различаются от языка к языку, от системы сборки к системе сборки и даже от проекта к проекту.

Если тебе надо configure и make, можешь почитать GNU Coding Standards (раздел 7 Release Process), исходники GNU Hello и мануал по autoconf.

Кстати, существует простой и понятный гайд по autoconf и automake? Недавно, чтобы перевести относительно сложный проект с 3rdparty крапом со скриптов на cmake мне хватило полчаса и документации в заголовках модулей cmake, за аналогичное время autoconf просто нагнал тоску.

Кстати, существует простой и понятный гайд по autoconf и automake?

Во всех книжных магазинах Китеж-града.

man autotools.

Да, наверное, я был слишком высокого мнения о FSF и ко.

Да, наверное, я был слишком высокого мнения о FSF и ко.

autotools - это система из разрозненных компонентов, которая постепенно выросла вокруг чистого make. Разумеется, более поздние системы проще в использовании, поскольку они учли опыт предыдущих.

Кстати, GNU Release Process вовсе не требует использования automake, но он требует наличия скрипта configure с определённым интерфейсом для удобства пользователей. Этот скрипт может быть враппером для другой системы сборки.

в правильно настроенном autoconf/automake проекте архив с исходниками создаётся автоматически командой «make dist»

FreeBSD Developers' Handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/

Руководство FreeBSD по созданию портов: https://www.freebsd.org/doc/ru_RU.KOI8-R/books/porters-handbook/

Посоветуйте, пожалуйста, где почитать о создании open-source пакетов исходных кодов. Ну, как принято, чтобы и configure и make и даже README, NEWS, Changelog, все что там вообще принято.

Это устаревшие GNU'шные традиции, их энфорсили autotools, которые сами по себе сейчас использовать крайне вредно.

Современные best practices требуют совсем немного - README или README.md с общим описанием, COPYING с лицензией, вменяемая сборочная система (для C/C++ - cmake) и, понятное дело, код. Остальное - по вкусу, но на самом деле чуть более чем во всех даже autotools'овских проектах эти NEWS и Changelog были пустыми или содержали мусор типа тупого лога vcs.

Так как autotools'овской лапши больше генерить не нужно, .tar.gz обычно содержит то же что и чекаут репозитория, и смысл в нём есть только когда есть части проекта, требующие отдельных тяжёлых зависимостей для сборки. Например, если иконки конвертятся из svn inkscape'ом, или спрайты для игры рендерятся blender'ом, или документация собирается каким-нибудь жирным tex'ом, лучше включить их в tar.gz в собранном виде. Если же такого нет то github, например, позволяет скачать любой тэг или вообще коммит в виде .tar.gz, и никаких архивов самому делать вообще не нужно (ну разве что за исключением случая когда у проекта есть submodules - они в .tar.gz не попадают).

По поводу документации, для консольного приложения читай про генерацию man (да, наверняка какой-нибудь что-то2man), хотя в идеале должно хватать описания ключей в --help. Для графического документация не нужна, но если очень хочется - смотреть как принято в используемом toolkit'е. Ну и можно на сайте уроки и примеры выложить.

Да, еще можно глянуть https://wiki.debian.org/UpstreamGuide, там много полезных советов есть.

Главное, чтоб make DESTDIR=$pkgdir install работал, были внятно описаны зависимости, ну и собиралась чтоб без танцев с бубном.

Традиции? В некоторых проектах в configure «haha, this is not automake project»...

Это устаревшие GNU'шные традиции, их энфорсили autotools, которые сами по себе сейчас использовать крайне вредно.

Кто их устарил и почему их использовать вредно?

Ну у них хоть tar сжатый а не просто переименованный?

++

ну это же tar