ما الإطار الذي يجب أن أستخدمه لكتابة الوحدات؟[مغلق]

Question

ما هو أفضل إطار لكتابة الوحدات - ExtUtils::MakeMaker (h2xs) أو الوحدة النمطية::بناء?

Answer 1

ملحوظة هذه النصيحة عفا عليها الزمن. تمت إزالة الوحدة النمطية::Build من قلب Perl ولكنه يعيش كوحدة CPAN.لا تزال الإيجابيات والسلبيات قائمة، ولا تزال آرائي حول MakeMaker قائمة.

---

باعتباري المشرف السابق على ExtUtils::MakeMaker، أود أن أوصي بـ Module::Build لأن MakeMaker هو عرض رعب.الوحدة النمطية :: Build هي أفضل بكثير.لكن هذه ليست مخاوفك وسأقدم إجابتي "الأقل إزعاجًا بالنسبة لك".

ملخص تنفيذي:

نظرًا لأن دعم Module::Build ليس متوافرًا بنسبة 100% من خلال لغة Perl بأكملها، فابدأ باستخدام MakeMaker.إذا كنت تريد إجراء أي تخصيص على الإطلاق، فانتقل إلى Module::Build.نظرًا لأن التصميم الأساسي والخيارات والواجهة متطابقة تقريبًا، فسيكون هذا غير مؤلم.بقدر ما يبدو مغريًا، تجنب Module::Install.

لحسن الحظ، يمكن لـ Module::Build محاكاة MakeMaker مما يساعد البعض، لكنه لا يساعد إذا كنت ستقوم بأي تخصيص.يرى الوحدة النمطية::Build::Compat.

بالنسبة لإصدارات CPAN، فإن استخدام Module::Build أمر جيد.هناك ما يكفي من الوحدة النمطية :: بناء الأشياء على CPAN الآن بعد أن تعامل الجميع مع تمهيدها بالفعل.

وأخيرا الجديد configure_requires يتيح الخيار لقذائف CPAN معرفة كيفية تثبيت Module::Build قبل أن يتمكنوا من البدء في إنشاء الوحدة.لسوء الحظ، فإن أحدث قذائف CPAN فقط هي التي تعرف عن تكوين_يتطلب.

أوه، أيًا كان ما تفعله، فلا تستخدم h2xs (إلا إذا كنت تكتب رمز XS...وحتى ذلك الحين فكر في الأمر).

إيجابيات ماك ميكر:

• يأتي مع Perl ويستخدمه Berl Core (وبالتالي يتم الحفاظ عليه بنشاط وسيظل كذلك إلى الأبد)
• كل شيء يعرف ما يجب فعله مع Makefile.PL.
• ستغطي معظم وثائق تأليف الوحدة MakeMaker.
• الاستخدامات (أولئك الذين يعرفون جعل يمكن تصحيح وتصحيح عملية البناء)

سلبيات MakeMaker:

• يتطلب الصنع (فكر في Windows)
• من الصعب التخصيص
• من الصعب جدًا تخصيص النظام الأساسي وإنشاءه
• من الصعب تصحيح الأخطاء عند حدوث خطأ ما (إلا إذا كنت تفهم ذلك)

الوحدة النمطية::بناء الايجابيات:

• أسهل للتخصيص/فئة فرعية
• بيرل النقي
• أسهل في التصحيح (إنها لغة Perl)
• يمكن محاكاة MakeMaker بعدة طرق
• ستقوم قذيفة CPAN بتثبيت Module::Build لك

الوحدة النمطية::بناء السلبيات:

• المشرفون على الوحدة النمطية::Build (وفي الواقع جميع أعضاء عصابة Perl Toolchain) يكرهونها
• الإصدارات الأقدم من عملاء CPAN (بما في ذلك CPANPLUS) لا تعرف أي شيء عن Module::Build.

الوحدة::تثبيت الايجابيات:

• واجهة سلسة
• حزم نفسها، لديك نسخة معروفة
• كل شيء يعرف كيفية التعامل مع Makefile.PL

الوحدة النمطية::تثبيت السلبيات:

• يتطلب صنع
• يستخدم دائمًا الإصدار المجمع، وهو عرضة للكسر الخارجي
• من الصعب التخصيص خارج واجهته
• يفسد شجاعة MakeMaker لذا فإن إصدار MakeMaker الجديد سيكسره في النهاية.
• لا يعرف كيفية إنشاء ملف meta باستخدام V2 Meta-Spec (على نحو متزايد مشكلة مع الأدوات الأحدث)

Answer 2

هناك سؤالان هنا.

أولاً، لا تستخدم أبداً h2xs.إنه أمر سيئ قديم عفا عليه الزمن، على الرغم من أنني أفترض أنك إذا كنت تحاول بالفعل تحويل ملف رأس إلى كود XS، فقد يكون ذلك مفيدًا (لم أفعل ذلك بنفسي).

تحديث 2011:أوصي بشدة بإلقاء نظرة على توزيع::زيلا, ، خاصة إذا كنت تعتقد أنك ستحافظ على أكثر من وحدة واحدة.

لإنشاء وحدة نمطية جديدة، استخدم Module::Starter.إنه يعمل بشكل رائع، ويحتوي على بعض المكونات الإضافية الرائعة لتخصيص الإخراج.

ثانيًا، أنت تسأل عن نظام البناء الذي يجب عليك استخدامه.المتنافسون الثلاثة هم ExtUtils::MakeMaker (EUMM)، وModule::Build (MB)، وModule::Install (MI).

يعد EUMM عملاً سيئًا للغاية، ولكنه يعمل، وإذا لم تقم بتخصيص عملية البناء الخاصة بك على الإطلاق، فإنه يعمل بشكل جيد.

MB هو الطفل الجديد، وله منتقديه.إنها ميزة كبيرة وهي أنه إذا كنت تريد تخصيص عملية التثبيت والإنشاء بشكل كبير، فمن الممكن جدًا القيام بذلك بطريقة عقلانية (وبطريقة مشتركة بين الأنظمة الأساسية) باستخدام ميغابايت.ليس من الممكن حقًا استخدام EUMM.

أخيرًا، MI هو في الأساس عبارة عن غلاف تعريفي أعلى EUMM.كما أنه يحزم نفسه مع التوزيعة الخاصة بك، في محاولة للتغلب على المشكلات مع المستخدمين الذين يحاولون تثبيت الوحدات النمطية باستخدام وحدات سلسلة الأدوات القديمة.الجانب السلبي لخدعة "الحزمة الذاتية" هو أنه إذا كان هناك خطأ في MI نفسه، فيجب عليك إعادة إصدار جميع الوحدات النمطية الخاصة بك فقط لإصلاحها.

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

Answer 3

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

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

أما بالنسبة لـ Makemaker والوحدة النمطية::Build، المستقبل هو الوحدة::Build.نحن فقط نحن الرجال القدامى نستخدم Makemaker بعد الآن.:) هناك طرق لاستخدام كليهما (أو التظاهر باستخدام كليهما) في نفس الوقت. انظر إلى مستندات الوحدة::Build، والوحدة النمطية::Build::Compat، والوحدة النمطية::Install.الوحدة النمطية::Build تم طردها من مكتبة Perl القياسية ومستقبلها غير مؤكد.لقد عاد الأمر إلى Makemaker كنظام بناء.

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

Answer 4

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

Answer 5

المشكلة الوحيدة في التوافق فيما يتعلق بـ Module::Build هي عندما يحاول المستخدم تثبيت الوحدات دون تحديث عميل CPAN الخاص به (CPAN.pm أو CPANPLUS.pm). إذا كانوا يقومون بتثبيت الوحدة الخاصة بك من CPAN، فيمكنهم ترقية عميلهم بنفس السهولة من نفس المرآة.

إذا كنت لا تريد أن تفعل أي شئ معقدة في عملية البناء الخاصة بك، بالتأكيد:استخدم EUMM.ولكن إذا كانت لديك مشكلة في البناء على نظام أساسي مستهدف مختلف، فقد ينتهي بك الأمر في ملف Makefile، والذي يختلف في كل نسخة مختلفة.

الوحدة النمطية::Build تمنحك الكثير من الميزات (أي شيء يمكنك التفكير فيه إذا قمت بتمديده) وكلها بيرل حتى لا ينتهي بك الأمر أبدًا إلى تصحيح أخطاء ملف تعريف.Module::Install يمنحك ميزات، ولكن يجب عليك تجميعها وسينتهي الأمر بتشغيل كل شيء من خلال "make" في النهاية.

Answer 6

أوصي أيضًا بـ Module::Build و Module::Starter (مع ملحق البرنامج المساعد TT2).

Answer 7

Module::Build أفضل بأي حال من الأحوال، لكنه أقل دعمًا على نطاق واسع من ExtUtils::MakeMaker (وبشكل أكثر تحديدًا، الإصدارات الأقدم من Perl لا تدعمها خارج الصندوق).ذلك يعتمد على الاحتياجات الخاصة بك.

Answer 8

أنا شخصياً أوصي بـ Module::Install، كما يفعل الكثير من الأشخاص الذين أعرفهم - يستخدمه أيضًا أمثال Catalyst وMoose.

Answer 9

فيما يلي توضيح بسيط للاتجاه الذي كنت آمل أن تتخذه الردود:

• إيجابيات/سلبيات مختلف الأطر
• التوافق/تثبيت قاعدة الأطر
• الملاءمة للداخلية (المحلية) مقابل.الإصدارات الخارجية (CPAN).
• لا إجابات "استخدم X" العارية

إجابة ديف لديه بعض المعلومات الجيدة المؤيدة/المعارضة. إجابة ليون يلمح إلى التوافق ولكنه ليس صريحًا.مثل ذكر بريان د فوي, ، القبعات القديمة فقط تستخدم EUMM، لكنني لست مقتنعًا بأن MB هي إطار عمل جيد للأشياء المخصصة لـ CPAN نظرًا لأنها ليست جزءًا من النواة حتى 5.9.

Answer 10

الاثنين لهم ايجابيات وسلبيات.في هذه الأيام أستخدم وأوصي بـ Module::Build و Module::Starter.

Answer 11

يبدو أن EU::MM هو الأكثر دعمًا وشعبية على نطاق واسع، ولكن Module::Build يلحق بالركب.أيضا، تحقق من الوحدة::بادئ للحصول على وحدة من شأنها أن تساعدك على البدء.