[linux] OT: Tarball packaging convention

[Ondrej Jombik]

                                        Maxim, 00:42:23
                                        23. april 2002 (utorok)
Zdravim.

> Mam tu na krku jeden hlupy projekt a kedze nikto zo zucastnenych nevie o
> UNIXoch vela, mam im zdokumentovat aj veci ako rozdiel medzi README a
> README.config, na co je Makefile a co obsahuje, ako pouzit loop device
> apod. Chcel som sa spytat hlavne na naming convention (README, INSTALL
> atd.) v src tarballoch, nie je niekde na nete? Bude totiz samozrejme
> podstatne jednoduchsie urobit cut and paste ako pisat vsetko z gruntu.

	Dufam, ze som spravne pochopil otazku. Je tu toho viac, snad si
najdete to co potrebujete vediet.

	Konvenciu pouziva kazdy vlastu. My z Platona konkretne takuto:

README - co to je a co to robi + prikaldy pouzitia
INSTALL - ako to nainstalovat, as simple as possible recommended
TODO - co treba este spravit, ludi tesi ked vidia, ze sa na tom pracuje
COPYING - licencia, obycajne GNU GPL
LICENSE - nepouzivame, ale sluzi na to iste
AUTHOR[S] - kto to spiskal
ChangeLog - zmeny od poslednej oficialnej verzie, v pripade ze ide o 
oficialnu verziu, zmeny od predposlednej

	Tieto su diskutabilne:

BUGS - toto my nepouzivame, nemame naco ;-)
FEATURES - ked ma program nejake nehorazne featury a su ludia co cchu 
do nich priamo skocit, tak su popisane tu
CHANGES - to iste co ChangeLog
NEWS - detto
API - opis API
SITES - toto vyzaduje tusim automake, ale (skoro) nik to nepouziva
CREDITS - toto som videl len v linuxovom jadre, zrejem substitucia za AUTHOR
MAINTAINER - detto
REPORTING-BUGS - ako a komu reportovat chyby, vo velkych projektoch 
nevyhnutne, pretoze ked sa to posle nespravnemu cloveku, nic z toho nebude

atd. atd.

	Co sa tyka toho README.config a README, odhadujem ze to prve bude
cisto o konfiguracii a druhe nejake vseobecne kecy. Dalej Makefile subor
sluzi na kompilovanie linkovanie a podobne. Da sa pouzit takmer na cokolvek
kde su zavislosti, nemusi to byt nutne kompilacia zdrojovych kodov. 

	Zavislostami sa mysli, ze nejaky subor potrebujena cinnosti
prekompilovanie (prerobenie) nejakeho ineho suboru. Pri DOBRE napisanom
Makefile sa kompiluje vzdy len to co je naozaj nevyhnutne. Zavyslosti sa
daju vytvarat automaticky dez dependencie a su ulozene v podadresari .deps/.

	Obycajne to funguje tak, ze sa spravia subory:

configure.in
config.h.in
Makefile.in

	Pomocou autoconf sa vygeneruje configure. V takomto stave sa spravi
./configure a z Makefile.in sa spravi Makefile. Potom 'make dist' (musi to
Makefile podproovat). Vytvori sa TGZ balik. V nom sa vsak nenachadza
Makefile.

	Ked to dorazi k zakaznikovi (koncovemu uzivatelovi) ten spravi opat
./configure so svojimi parametrami, vygenerujem mu to Makefile a config.h s
konfiguraciou a potom uz fici:

make, make test, make install, atd atd...

	Da sa este pouzivat automake, ale doteraz som/sme neprisli nato,
naco je to dobre. Sudiac podla ostatnych distribucii, vela ludi to
nepouziva. Generuje to z Makefile.am Makefile.in. Viac neviem, ale ked
uvidis Makefile.am a nic ine, tak ver ze napisanie automake to riesi. :-)

	Zaujimavym suborom je tiez Doxyfile, casto generovany configure
skriptom z Doxyfile.in, ktory sluzi ako konfigurak pre Doxygen. Doxygen
generuje developersku dokumentaciu priamo zo zdrojakov. Ak take potrebujete,
odporucam sa na to pozriet. Inak na uzivatelsku dokumentaciu samozrejme
DocBook.

	To je asi tak v skratke vsetko. Cast o loop device som nepochopil. 
Myslel si Local Loopback?

	=Nepto=
____________________________________________________________________________
Ondrej 'Nepto' Jombik, perl -le '$_=1;(1x$_)!~/^(11+)\1+$/&&print while$_++'