يمكن autotools إنشاء منصة متعددة makefiles

Question

لدي المساعد المشروع لقد تم تطوير لبضع سنوات حيث البرنامج المساعد يعمل مع العديد من تركيبات من [الابتدائي تطبيق نسخة مكتبة 3rd الطرف الإصدار 32 بت مقابل64 بت].هل هناك (نظيفة) طريقة استخدام autotools إلى إنشاء واحدة makefile أن يبني جميع إصدارات البرنامج المساعد.

بقدر ما أستطيع أن أقول من القشط من خلال autotools الوثائق الأقرب إلى ما أود أن يكون ن المستقلة نسخ من المشروع ، ولكل منها makefile.هذا يبدو قليلا الأمثل لاختبار والتنمية (أ) يجب أن باستمرار نشر التغييرات في التعليمات البرمجية في جميع نسخ مختلفة و (ب) هناك الكثير من مساحة مهدرة في تكرار المشروع مرات عديدة.هل هناك طريقة أفضل ؟

تحرير:

لقد تم المتداول بلدي حل لفترة من الوقت حيث كنت قد يتوهم makefile وبعض البرامج النصية perl لمطاردة مختلف مكتبة 3rd الطرف الإصدارات ، وما إلى ذلك.على هذا النحو, أنا مستعد أخرى غير autotools الحلول.من أجل بناء أدوات أخرى, أريد منهم أن يكون من السهل جدا بالنسبة للمستخدمين النهائيين إلى تثبيت.الأدوات تحتاج أيضا إلى أن تكون ذكية بما يكفي لمطاردة مختلف 3rd الطرف المكتبات ورؤوس دون كمية ضخمة من المتاعب.أنا في الغالب تبحث عن لينكس حل ، ولكن ذلك أيضا يعمل على ويندوز أو ماك سيكون مكافأة.

Answer 1

بقدر ما أعرف, لا يمكنك أن تفعل ذلك.ومع ذلك ، أنت عالق مع autotools?لا CMake ولا SCons الخيار ؟

Answer 2

إذا كان سؤالك هو:

هل يمكنني استخدام autotools على بعض آلة إلى إنشاء واحدة العالمي makefile التي سوف تعمل على جميع الآلات ؟

ثم الجواب هو "لا".على autotools لا تجعل حتى التظاهر في محاولة للقيام بذلك.هم صممت أن تحتوي على رمز المحمولة التي ستحدد كيفية إنشاء عملي makefile على الجهاز المستهدف.

إذا كان سؤالك هو:

هل يمكنني استخدام autotools إلى تكوين البرامج التي تحتاج إلى تشغيل على أجهزة مختلفة ، مع إصدارات مختلفة من البرامج الأساسية التي يعمل بها البرنامج المساعد مع, بالإضافة إلى مختلف 3rd الطرف المكتبات ، ناهيك عن 32 بت مقابل 64-بت القضايا ؟

فإن الجواب هو "نعم".على autotools مصممة لتكون قادرة على القيام بذلك.كما عمل على يونكس, لينكس, ماك X, BSD.

لدي برنامج المساعدة SQLCMD (التي يعود تاريخها إلى ما قبل Microsoft البرنامج من نفس الاسم من قبل أكثر من عقد من الزمن) ، الذي يعمل مع IBM ينفورميكس قواعد البيانات.يكشف الإصدار من برنامج العميل (يسمى IBM ينفورميكس ESQL/C, جزء من IBM ينفورميكس ClientSDK أو CSDK) مثبت ، سواء كان 32 بت أو 64 بت.كما يكشف أي إصدار من تثبيت البرنامج, مع وظائفه إلى ما هو متاح في دعم المنتج.وهو يدعم الإصدارات التي تم إصدارها على مدى فترة من حوالي 17 سنة.فمن autoconfigured -- كان لي أن أكتب بعض autoconf وحدات الماكرو من أجل ينفورميكس وظيفة لبضعة الادوات الأخرى (عالية الدقة والتوقيت وجود /dev/ستدين الخ).ولكنها غير قابلة للتنفيذ.

من ناحية أخرى, لا تحاول الافراج عن واحد makefile التي تناسب جميع العملاء آلات البيئات;هناك الكثير من الاحتمالات أن تكون معقولة.ولكن autotools يأخذ الرعاية من التفاصيل بالنسبة لي (و المستخدمين).كل ما يفعلونه هو:

./configure

هذا هو أسهل من العمل على كيفية تحرير makefile.(يا لأول 10 سنوات ، البرنامج تم تكوينه عن طريق اليد.كان من الصعب على الناس أن تفعل, حتى ولو كان جيد جدا التخلف اقامة.ولهذا السبب انتقلت إلى التكوين التلقائي:فإنه يجعل من أسهل بكثير من الناس إلى تثبيت).

---

السيد Fooz قائلا:

أريد شيء بين بين.العملاء استخدام إصدارات متعددة و bitnesses من نفس قاعدة التطبيق على نفس الجهاز في حالتي.أنا لست قلقا عبر تجميع مثل بناء ويندوز الثنائيات على لينكس.

هل تحتاج منفصل بناء البرنامج المساعد الخاص بك 32 بت و 64 بت الإصدارات ؟ (افترض نعم - ولكن هل يمكن أن مفاجأة لي.) لذلك تحتاج إلى توفير آلية للمستخدم أن أقول

./configure --use-tppkg=/opt/tp/pkg32-1.0.3

(حيث tppkg هو رمز حزمة طرف ثالث, و الموقع هو specifiable من قبل المستخدم.) لكن, نضع في اعتبارنا الاستخدام:أقل هذه الخيارات للمستخدم وقد أن تقدم أفضل ؛ ضد أن لا رمز القرص الثابت الأشياء التي يجب أن تكون اختيارية ، مثل تثبيت المواقع.بكل الوسائل البحث في المواقع الافتراضية - هذا جيد.و الافتراضي إلى bittiness من هذا البحث.ربما إذا وجدت كل من 32 بت و 64 بت, ثم يجب أن نبني على حد سواء-التي تتطلب حذرا البناء ، على الرغم من.يمكنك دائما أردد "التحقق من TP-حزمة ..." وبيان ما وجدت و حيث وجدته.ثم المثبت يمكن تغيير الخيارات.تأكد من الوثيقة './configure --help'ما هي الخيارات;هذا هو المعيار autotools الممارسة.

لا تفعل أي شيء التفاعلية على الرغم ؛ تكوين البرنامج النصي تشغيل الإبلاغ عما يفعل.Perl Configure السيناريو (لاحظ حرف - هو وهي منفصلة التكوين التلقائي نظام) هو واحد من عدد قليل مكثف التفاعلية التكوين نظم اليسار (وربما كان هذا هو أساسا بسبب تراثها.إذا بدأت من جديد ، فإنه من المرجح أن تكون غير تفاعلية).هذه النظم هي أكثر من مصدر إزعاج إلى تكوين غير التفاعلية.

عبر تجميع صعبة.لم يلزم أن تفعل ذلك ، والحمد لله.

---

السيد Fooz أيضا قائلا:

شكرا على تعليقات إضافية.أنا أبحث عن شيء مثل:

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2

حيث أنه من شأنه أن يخلق على حد سواء 32 بت و 64 بت أهداف في makefile على النظام الأساسي الحالي.

حسنا, أنا متأكد من أنه يمكن القيام به ؛ أنا لا أعتقد أن الأمر يستحق القيام بالمقارنة مع اثنين من تكوين منفصلة يعمل مع بناء كاملة في ما بين.ربما كنت ترغب في استخدام:

./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2

وهذا يدل على اثنين أدلة منفصلة.عليك أن تقرر كيف كنت تنوي القيام به بناء ، ولكن يفترض أن لديك اثنين من الدلائل الفرعية ، مثل 'obj-32'و 'obj-64'لتخزين مجموعات منفصلة من وجوه الملفات.كنت أيضا ترتيب makefile على غرار:

FLAGS_32 = ...32-bit compiler options...
FLAGS_64 = ...64-bit compiler options...

TPPKG32DIR = @TPPKG32DIR@
TPPKG64DIR = @TPPKG64DIR@

OBJ32DIR = obj-32
OBJ64DIR = obj-64

BUILD_32 = @BUILD_32@
BUILD_64 = @BUILD_64@

TPPKGDIR =
OBJDIR   =
FLAGS    =

all:    ${BUILD_32} ${BUILD_64}

build_32:
    ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build

build_64:
    ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build

build:  ${OBJDIR}/plugin.so

يفترض هذا البرنامج المساعد سوف تكون مشتركة الكائن.الفكرة هنا هي أن autotool من شأنها الكشف عن 32 بت أو 64 بت يثبت للطرف الثالث حزمة, ثم جعل بدائل.على BUILD_32 الكلي أن build_32 إذا كان 32 بت حزمة المطلوبة و تترك فارغة على خلاف ذلك ؛ على BUILD_64 الكلي سيكون التعامل معها بالمثل.

عندما يقوم المستخدم 'make all', فإنه سيتم بناء build_32 الهدف الأول build_64 الهدف التالي.لبناء build_32 المستهدفة, فإنه سيتم إعادة تشغيل make وتكوين الأعلام على بناء 32 بت.وبالمثل ، من أجل بناء build_64 المستهدفة, فإنه سيتم إعادة تشغيل make وتكوين أعلام 64-bit بناء.المهم أن كل الأعلام تتأثر 32 بت مقابل 64-بت يبني على العودية الاحتجاج make, وأن قواعد بناء الأجسام و مكتبات مكتوبة بعناية - على سبيل المثال ، حكم تجميع المصدر إلى كائن يجب أن تكون حذرا مكان ملف الكائن في الصحيح كائن الدليل باستخدام دول مجلس التعاون الخليجي ، على سبيل المثال ، يمكنك تحديد (في .c.o القاعدة):

${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c

الماكرو CFLAGS تشمل ${أعلام} القيمة التي تتعامل مع بت (على سبيل المثال ، FLAGS_32 = -m32 و FLAGS_64 = -m64, and so when building the 32-bit version,أعلام = -m32would be included in theCFLAGS` الماكرو.

المسائل المتبقية في autotools هو العمل على كيفية تحديد إصدار 32-بت و 64-بت الأعلام.إذا كان وفي أسوأ عليك كتابة وحدات الماكرو على ذلك بنفسك.ومع ذلك كنت اتوقع (دون بحث) التي يمكنك أن تفعل ذلك باستخدام معيار المرافق من autotools جناح.

إلا إذا كان يمكنك إنشاء نفسك بعناية (حتى بلا رحمة) متماثل makefile, لن تعمل بشكل موثوق.

Answer 3

لقد حاولت ذلك وأنه لا يعمل!لذلك نحن نستخدم الآن SCons.

بعض المقالات على هذا الموضوع: 1 و 2

تحرير: بعض مثال صغير لماذا أحب SCons:

env.ParseConfig('pkg-config --cflags --libs glib-2.0')

مع هذا الخط من التعليمات البرمجية يمكنك إضافة سطحي إلى تجميع البيئة (env).و لا تنسى دليل المستخدم وهو مجرد كبيرة لتعلم SCons (لم يكن لديك حقا أن تعرف الثعبان!).بالنسبة للمستخدم النهائي قد تتمكن من محاولة SCons مع PyInstaller أو شيء من هذا القبيل.

و في مقارنة make, يمكنك استخدام بيثون ، لذا كاملة لغة برمجة!مع هذا في الاعتبار يمكنك أن تفعل كل شيء فقط (أكثر أو أقل).

Answer 4

هل فكرت في استخدام مشروع واحد مع عدة بناء الدلائل ؟ إذا كان الخاص بك automake المشروع ينفذ بطريقة سليمة (أي:ليس مثل دول مجلس التعاون الخليجي)

التالية ممكنة:

mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]

كنت قادرا على تمرير معلمات التكوين المختلفة مثل تتضمن الدلائل المجمعين (عبر المجمعين أي).

ثم يمكنك حتى تشغيل هذا في واحد إجراء مكالمة عن طريق تشغيل

make -C build1 -C build2 -C build3