أدوات جنو التلقائية

مجموعة أدوات GNU Autotools ، المعروفة أيضًا باسم نظام بناء GNU ، هي حزمة من أدوات أتمتة البناء المصممة لدعم بناء شفرة المصدر وتغليف الملفات الثنائية الناتجة. تدعم هذه المجموعة بناء قاعدة بيانات برمجية لأنظمة متعددة دون الحاجة إلى تخصيص الشفرة أو تعديلها . وهي متوفرة في العديد من توزيعات لينكس وبيئات يونكس .

تُعدّ Autotools جزءًا من مجموعة أدوات GNU ، وتُستخدم على نطاق واسع في العديد من البرامج الحرة وحزم البرامج مفتوحة المصدر . أدواتها المكونة هي برامج حرة ، مرخصة بموجب رخصة جنو العمومية العامة مع استثناءات خاصة من الترخيص ^{[ 1 ] [ 2 ]} تسمح باستخدامها مع البرامج الاحتكارية .

قد يكون من الصعب جعل برنامج قابلاً للنقل. تختلف المترجمات من نظام لآخر، وتفتقر بعض وظائف المكتبات إلى بعضها، وقد تحمل ملفات المترجم (مثل ملفات رأس C) أسماءً مختلفة، كما قد تُجمَّع المكتبات المشتركة وتُثبَّت بطرق مختلفة. إحدى طرق التعامل مع اختلافات المنصات هي كتابة كود مُجمَّع شرطيًا (أي باستخدام `autotools` #ifdef)، ولكن نظرًا لتنوع بيئات البناء، يصبح هذا الأسلوب غير عملي بسرعة. صُمِّمت Autotools لمعالجة هذه المشكلة بطريقة أكثر سهولة.

تتكون مجموعة أدوات التشغيل التلقائي من أدوات GNU المساعدة Autoconf و Automake و Libtool . ^{[ 3 ]} وتشمل الأدوات الأخرى ذات الصلة GNU make و GNU gettext و pkg-config ومجموعة مترجمات GNU (GCC).

تُسهّل أداة Autotools مشاركة البرامج متعددة المنصات مع شريحة واسعة نسبيًا من المستخدمين. فهي تُيسّر مشاركة شفرة المصدر من خلال توفير دعم قوي نسبيًا لبناء البرامج عبر المنصات المختلفة، مما يُمكّن المستخدمين من بناء البرنامج بأنفسهم. عادةً، تُوزّع شفرة المصدر مع سكربت يُسمى configure ، لا يعتمد على أي شيء سوى بيئة سطر أوامر متوافقة مع Bourne . لا يلزم توفر Autotools. يقوم المستخدم بتشغيل الأمر الذي يُنشئ ملفات متنوعة، بما في ذلك ملف Makefile الذي يستخدمه المستخدم عن طريق تشغيل الأمر . ^{[ 4 ] [ 5 ]}configuremake

يمكن استخدام أدوات Autotools لبناء البرامج الأصلية على جهاز البناء وكذلك للترجمة المتقاطعة إلى بنى معمارية أخرى. ^{[ 6 ]}

يُمكن أيضًا تجميع البرامج لتشغيلها على نظام ويندوز من نظام لينكس أو أي نظام بناء شبيه بيونكس آخر، باستخدام MinGW. مع ذلك، يُفضّل غالبًا التجميع الأصلي على أنظمة التشغيل (مثل أنظمة مايكروسوفت ويندوز ) التي لا تدعم تشغيل نصوص Bourne shell بشكل مستقل. هذا يجعل بناء هذه البرامج على نظام ويندوز أكثر صعوبة من بنائها على نظام شبيه بيونكس يوفر Bourne shell كمكوّن أساسي. يُمكن تثبيت نظام Cygwin أو MSYS على ويندوز لتوفير طبقة توافق شبيهة بيونكس ، مما يسمح بتشغيل نصوص التهيئة . يوفر Cygwin أيضًا مجموعة مُجمّعات GNU ، و GNU make ، وبرامج أخرى تُوفّر نظامًا شبيهًا بيونكس شبه كامل داخل ويندوز؛ كما يوفر MSYS أيضًا GNU make وأدوات أخرى مُصممة للعمل مع إصدار MinGW من GCC.

يمكن للمستخدم إعادة إنشاء سكربت التهيئة، وهو أمر قد يكون ضروريًا في حال تعديل شفرة المصدر. في هذه الحالة، يجب تثبيت برنامج Autotools.

قد يكون نص التهيئة المُنشأ بواسطة autoconf بطيئًا لأنه يُشغّل برامج مثل مُترجم لغة C عدة مرات لاختبار وجود المكتبات وملفات الرأس وميزات اللغة المختلفة. يؤثر هذا بشكل خاص على Cygwin ، الذي قد يُشغّل نصوص التهيئة بشكل أبطأ بكثير من نظام Linux نظرًا لافتقاره إلى استدعاء نظام fork أصلي . ^{[ 7 ]}

في عموده في ACM Queue ، انتقد مطور FreeBSD بول هينينغ كامب نظام بناء GNU: ^{[ 8 ]}

الفكرة هي أن يقوم برنامج التهيئة بتنفيذ حوالي 200 اختبار آلي، حتى لا يُضطر المستخدم إلى تهيئة مكتبة libtool يدويًا. هذه فكرة سيئة للغاية، وقد وُجهت إليها انتقادات لاذعة منذ ظهورها في ثمانينيات القرن الماضي، لأنها تسمح لشفرة المصدر بالتظاهر بأنها قابلة للنقل خلف واجهة برنامج التهيئة، بدلًا من أن تتمتع بميزة قابلية النقل أصلًا. من المؤسف حقًا أن فكرة التهيئة هذه قد نجت.

يرسم كامب تاريخ نظام البناء في مشاكل قابلية النقل المتأصلة في العديد من متغيرات يونكس في ثمانينيات القرن الماضي ، ويأسف على الحاجة إلى وجود أنظمة بناء كهذه:

لا تزال أسطر التكوين البالغ عددها 31085 سطرًا لـ libtool تتحقق مما إذا كان <sys/stat.h> و <stdlib.h> موجودين، على الرغم من أن نظام Unixen، الذي كان يفتقر إليهما، لم يكن لديه ذاكرة كافية لتنفيذ libtool ولا أقراص كبيرة بما يكفي لشفرة المصدر الخاصة به التي تبلغ 16 ميجابايت.

على الرغم من أن منتقدي أدوات Autotools غالبًا ما يدعون إلى بدائل توفر سهولة أكبر لمستخدميها، إلا أن البعض يرى أن هذا ليس بالضرورة أمرًا جيدًا. وقد أبدى جون كالكوت، مؤلف ^{كتاب Autotools ،} الطبعة الثانية: دليل عملي لـ GNU Autoconf وAutomake وLibtool ، رأيه في ^{هذا الشأن .}

تُعدّ أدوات Autotools أكثر شفافية من أي أدوات بناء أخرى متوفرة. فجميع الأدوات الأخرى ( مثل cmake و maven وغيرها) - التي تدّعي أنها أبسط بكثير لأنها تعزل المستخدم عن تفاصيل عملية البناء - يكمن عيبها الرئيسي في أن هذا العزل يمنع المستخدمين من إجراء التغييرات اللازمة لتحقيق أهداف البناء الخاصة بمشاريعهم.

أي شخص لا يملك إلا كلمات الثناء على هذا الجانب من CMake أو Maven أو Gradle أو غيرها، لم يسبق له العمل على مشروع يتطلب منه الابتعاد بشكل كافٍ عن الإعدادات الافتراضية. لقد استخدمتُها جميعًا، وقضيتُ ساعاتٍ في إحباطٍ شديدٍ محاولًا إيجاد حلولٍ لتجاوز قصور بعض وظائف الأدوات التي تُنفّذ كل شيء (باستثناء ما أريده). هذه ليست مشكلةً مع Autotools. كما ذكر أحدهم سابقًا في هذه المناقشة، يمكنك إضافة سكربت شل إلى ملف configure.ac، وسكربت make إلى ملف Makefile.am. هذا هو تعريف الشفافية بحد ذاته. لا توجد أداة أخرى تُتيح هذا المستوى من المرونة.

• قائمة برامج أتمتة البناء

• يوفر موقع buildconf على SourceForge برنامج autogen.sh النصي لإعداد البناء التلقائي لنظام posix shell.