GNU autotools-ийн товч танилцуулга

Linux, Unix хэрэглэгчдийн дунд C/C++ дээр бичигдсэн програмыг соорсоос нь хөрвүүлэн суулгах, тохируулахтай холбоотой бэрхшээл маш их тохиолддог. Харин хөгжүүлэгчдийн дунд нэг програм бичээд бүх орчин дээр ажиллахаар хийхтэй холбоотой бэрхшээл маш их өргөн байдаг. Энэ бүгд чухам юунаас болдог вэ?

Эдгээр бэрхшээлийг бага ч гэсэн шийдвэрлэдэг болоход чухал хэрэгтэйн учир GNU autotools-ийн талаар товч дурдая гэж бодлоо.

Хэрэв миний энд бичихийг алгасан энэ багажуудыг бие даан судлахаар бол дараах 2 материалыг энд байгаа дарааллаар уншаарай. Мэдээж энгийн хэрэглэгчид бол уншаад хэрэггүй. Хөгжүүлэгчид, ситемийн админ гэх мэт техникийн мэргэжлийнхэн үзэж болно.

1. http://www.lrde.epita.fr/~adl/autotools.html

2. http://sourceware.org/autobook/autobook/autobook_toc.html#SEC_Contents

Дээрх материалуудын уншихаасаа өмнө юу болох тухай товч танилцуулга өөрийн хар үгээр товч тайлбар бичие. (Албан ёсны он сар, албан газар, хүний нэрсийг мэдээж санахгүй байгаа тул нарийвчилж уншцгаана биз)

Unix-ийг түүхийн хувьд аваад үзвэл анх 1969 онд манийг төрөхөөс өмнө бичигдсэн юм гэдэг. Энэ нь далаад онуудад худалдагдах нь зөвшөөрөгдөөгүй байх үедээ их сургуулиудад маш хямд үнээр түгж байж. Ингэж байтал наяаад оноос эхлээд худалдаалах эрхийг AT&T хамгийн анхлаад ар араас нь Sun, HP эдэр гэсэн акулууд худалдаалж эхэлснээс хойш Unix-ийн хувилбар хоорондоо ялгаатай болоод салбарлаж эхлэсэн байгаа юм. Гэхдээ хооронд нэгтгэсэн стандарт огт байхгүй байлаа. Дараа нь нэгтгэх зорилготой стандартартууд гарч. Яг үнэндээ одоо ч POSIX стандарт бүрэн зангидаж чадаагүй сунжирсаар л байгаагийн зэрэгцээгээр POSIX-рүү нийцүүлж байгаа хугацааны дарааллаар нэгэн ижил бишээр бага багаар цэгцэрч байгаа.

Энгийн жишээнүүд аваад үзэхэд strndup, strnlen, strsignal гэх мэт хамгийн энгийн функцүүд ч одоо HP-UX дээр нь байхгүй, Linux дээр байгаа гэх мэт. BSD дээр memcpy байхгүй ч байх шиг. PATH_MAX гэх мэт define зарим дээр нь байхгүй эсвэл header файл нь ондоо гэх мэт зовлонтой байдал одоо ч байсаар л байгаа.

Яг энэ асуудлаас болоод л C/C++ дээр програм бичихэд нэг кодоор аль дээр нь ч ажилладаг, суулгадаг програм хялбар бичигддэггүй. Хөгжүүлэгч тухайн үед аль нэг орчинд хийдэг харин түүнийгээ бүх орчинд тест хийж чаддаггүй. Чадах байлаа ч тухайлбал FreeBSD-ийн бүх хувилбар дээр шалгаж амждаггүй. Гэтэл FreeBSD нь зарим толгой файл, функцүүд нь POSIX стандартруу хэдийд аль хувилбараасаа нийцэж эхлэсэн гэх мэт нь хянах нь төвөгтэй. Цаашлаад C/C++ хэлний хөрвүүлэгчид ч олон, тэдгээрийн хэрэглэх арга нь ялгардагаас хамаараад хөрвүүлэх үйл ажиллагаа ч ялгаатай болдог. (Ямар хөрвүүлэгчөөр ямар орчинд хөрвүүлэхээс хамаараад биелэлт хурдны асуудал ч үнэндээ яригдах нь мэдээж ч энэ тусдаа дангаараа том сэдэв болох нь мэдээж хэрэг. Жишээ нь GNU хөрвүүлэгчийн хувьд cross буюу олон орчинд ажиллах хөрвүүлэлт болон C-с бусад хэлийг хөрвүүлдэг гээд л яриа үргэлжлэх байх)

Энэ бүх бэрхшээлийг шийдэх зорилгоор GNU autotools гэж нэрлэгдэх autoconf, automake, libtool, configure гэх мэт багажууд хийгдсэн байна. Энэ багажуудын зарим гол санаанаас хэлбэл:

1. Configure гэх bourne shell скрипт нь ямар орчин дээр ажиллах гэж байгаагаас хамаарч Makefile-уудыг тухайн орчинд нь тааруулж үүсгэдэг. Гэхдээ Makefile.in гэх файлуудыг оролтондоо авч үүсгэдэг.

2. Дээрх Makefile.in -ийг аваад үзвэл мөн л нилээн том файлууд болдог тул хөгжүүлэгчид гараараа үүсгэх нь бас л цагийг авсан хар ажил болдог. Иймээс энэ файлыг үүсгэдэг automake гэсэн багаж хийгдэж. Makefile.am гэсэн бичиглэлийг маш хөнгөвчилсөн хялбар файлыг бичээд тэндээсээ automake багажаар Makefile.in үүсгэдэг.

3. Configure скрипт нь гэтэл бас л нэг ерөнхий байдлаар бичих боломжгүй буюу хөгжүүлэгчид өөрийн хэрэгцээнд нийцүүлэн configure скриптийг өөрчлөх хэрэгтэй болдог. Гэтэл энэ скрипт нь олон жилийн турш хөгжиж ирсэн маш төвөгтэй томоохон скрипт юм. Иймээс хялбар үүсгэх аргыг бас л бодож олж. configure.ac гэх бичихэд хялбар файл бичээд эндээс autoconf багажаар configure.in болон configure скриптыг үүсгэдэг.

4. Дээрх 1,2,3-т дурдсанаас гадна нэгэнт бичигдсэн програм дотор орчноос хамаарсан зүйлс байгаа эсэхийг хайдаг багаж, тэндээсээ үндэслээд configure.ac файл ямархуу байхыг таамаглах багаж, энд дурдсан багажуудыг бүгдийг нь зөв дарааллаар нэг мөр ажиллуулдаг багаж гээд өөр зөндөө олон багажууд хийгдсэн байдаг тул хэрэглэхэд ихэд хялбар болсон байдаг.

5. Хөгжүүлэлтийн компьютер дээрээ gnu autotools-ийг суулгасан байхдаа дээрх configure скрипт болон Makefile.in файлуудыг үүсгэчихвэл дараа нь аль ч OS дээр нэг л аргаар хөрвүүлж суулгах боломжтой болдог.

Ингээд бэлэн болсон соорсыг эцсийн хэрэглэгч

configure

make

make install

гээд л хөрвүүлээд суулгах асуудал. Гэвч энэ нь бүх орчин дээр санасан зоргоор явагдахгүй тул configure скриптыг ажиллуулахдаа дамжуулах олон параметрээр зохицуулах ажилууд шаардлагатай болох нь бий. Жишээ нь: /usr/include дотор толгой файлууд нь байхгүй бол хаана байгаа газарыг нь INCLUDES хувьсагчид заахаас эхлэнэ. Цаашлаад link хийхтэй холбоотой зүйлс, хэрэглэгдсэн функц байгаа байхгүйгээс хамаараад орлуулалт хийх, суулгах байрлал, суулгах директорын бүтэц гээд л зөндөө зүйлсийг зааж болдог. Бүр цаашлаад эцсийн суулгах тархацуудыг ч үүсгэж болно.

Ингээд соорсыг хөрвүүлж суулгах нь зарим орчин дээр бас л хялбар биш ажил болж хувирдаг. Хичнээн gnu autotools ашиглан gnu бүтэцтэй төсөл бичсэн байлаа ч зарим Unix дээр хөрвүүлэлт нь бас л төвөгтэй. Жишээлбэл HP-UX дээр харгалзах олон gnu төслүүд ирдэггүй. Хэдийгээр gnu төслүүдийг бүгдийг нь HP-UX дээр port хийж оруулсан depot файлууд байдаг ч гэлээ бүх багцийн хамаарлыг нь тооцож оруулах хар ажил нь хэрэглэгчийн ажил болж хувирдаг учир дутагдалтай.

Ингээд ямар орчинд суулгах хамаарлыг зохион байгуулах package management хэлбэррүү шилжиж хялбарчилсан байдаг. Дээрх gnu autotools ч гэсэн багцийн хамаарлыг шалгах боломжоор хангагдсан байдаг. Мөн gnu бүтцээр бичигдсэн төслөөс debian болон rpm багц үүсгэх нь тийм ч хэцүү биш байдаг тул package management-ийн талаар цаашид тусдаа дурдсан нь дээр байх.

Гэх мэтээр мэдээж хэрэг autotools-ийн тухай ярих нь хамрах хүрээ нилээн өргөн тул энд блогийн ганц бичлэгээр дурдахад хэцүү юм байна. Харин асуух зүйлс байвал ерөнхий болон нарийвчилсан асуулт аль ч байсан асуувал чөлөөтэй хариулах болно.

5 comments:

  Bibby

December 26, 2008 at 7:06 AM

Танийг энэ талаар хөндөж бичиж бгаад баяртай бна. Миний хувьд сүрхий прожект энэ тэр бичээд, майкфайл энэ тэр үүсгэж яваагүй ч, энэ талын мэдлэггүйгээс зөндөө бэрхшээлтэй тулгарч блаа. Үргэлжлүүлэн бичнэ гэдэгт найдаж бна. Баярлалаа.

  Эрхэмээ

December 26, 2008 at 7:18 AM

Энэ сэдвийг сайхан тайлбарлаж бичсэн нь cross platform develop сонирхогч, эхлэгчдэд их хэрэгтэй зүйл болжээ. Хөдөлмөр, сэтгэл гаргаж бичсэнд бас баярлаж байна. ;)
Миний хувьд RH7-с эхлээд л элдэв янзын программ суулгах гэж их л үйл тамаа идэж, хайран цаг хугацааг нилээд алдаж байсан. Сүүлд харин Debian Sarge суулгаж ашиглаж үзээд Fedora, Suse гэж явж байхынхаа оронд эртхэн шиг Debian ашиглаад aptitute ашиглаж байх юм яаваа гэж харамсаж байсан шүү.
Би анх 2002 онд монголын анхны нээлттэй програм Archer (archiver) эдэр гэж сүржин нэр өгөөд нэг даржин программ бичиж байсан. yacc, lex ашиглаад config file parser маягийн... Санажийна уу :)

  Эрхэмээ

December 26, 2008 at 7:22 AM

Тэгэхэд 5р курст диплом бичиж байсан. Интерком гээд тэмцээн зарлагдахаар нь энэ archer-ыг autotools ашиглаж бичээд яг дуусч байсныг хэлэх үү, явуулаад орхитол бараг түрүүлэнгээ алдаад ам хүзүүдээд наадагийн. хэхэ. Тухайн үедээ Линукс орчинд бичсэн гээд л тэгсэн байх... Оюутан насны дурсамж сэргэчихлээ ;D

  Dulmandakh

December 28, 2008 at 5:26 PM

маш чухал хэрэгтэй сэдвээр бичсэн байна, баярлалаа.

  gobi

December 28, 2008 at 8:11 PM

Bibby makefile бичихийг нарийвчлан үзэхийн оронд GNU autotools-ийг шууд үзвэл илүү хялбар бөгөөд илүү давуу талтай байна гэсэн үүднээс танилцуулая гэсэн санааг агуулж бичсийн.

Эрхэмээгийн хэлснээр эцсийн хэрэглэгчийн хувьд debian package management бол хамгийн хэрэглэхэд хялбар нь. Гэхдээ хэрвээ өөрөө Си дээр хөгжүүлэлт хийхээр бол rpm нь дээр юм шиг надад санагддаг. Тиймээс би одоо гэртээ Си/Си++-ийн хөгжүүлэлт хийгээд байдаггүй тул гэртээ бол Ubuntu хэрэглэдэг мөртөө ажил дээр Fedora хэрэглэдэг. Тэгээд ч албан ажилд хэрэглэгдэх программууд ганц commercial үйлдлийн систем болох Redhat дээр ажиллуулах шаардлага тавигддаг тул Fedora дээрх хөгжүүлэлтээ хийх нь олон давуу талтай байдаг.