makepp_build_check - عبر الإنترنت في السحابة

برنامج:

اسم

makepp_build_check - كيف يقرر makepp إعادة إنشاء الملفات

الوصف

A: "architecture_independent"، E: "تطابق تام"، I: "ignore_action" ، O: "only_action"،
T: "target_newer"

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

يختار Makepp عادةً طريقة فحص الإنشاء الصحيحة تلقائيًا. ومع ذلك ، يمكنك ذلك
قم بتغيير طريقة التوقيع لقاعدة فردية باستخدام: build_check modifier على
القاعدة ، أو لجميع القواعد في ملف makefile باستخدام تعليمة build_check ، أو للجميع
makefiles مرة واحدة باستخدام خيار سطر الأوامر -m أو --build-check-method.

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

البناء التحقق طرق شامل in هيه توزيع
في الوقت الحالي ، هناك خمس طرق للتحقق من البناء مدرجة في التوزيع:

تطابق تام
تستخدم هذه الطريقة تواريخ التعديل في الملف كتوقيعات. يعيد بناء
الأهداف ما لم تتحقق جميع الشروط التالية:

· توقيع كل تبعية هو نفسه كما كان في البناء الأخير.

· توقيع كل هدف هو نفسه كما كان في البناء الأخير (أي لا أحد
لقد عبث بالأهداف منذ أن قامت makepp ببنائها).

· أمر البناء لم يتغير.

· لم تتغير بنية الآلة (أو ما يعتقده بيرل).

"المطابقة الدقيقة" هي الطريقة الافتراضية إلا إذا كنت تعيد إنشاء ملف Makefile (انظر أدناه).
هذه طريقة موثوقة للغاية لضمان الإنشاءات الصحيحة ، وهي دائمًا ما تكون كذلك
انت تريد. ومع ذلك ، فإن له بعض الآثار الجانبية التي قد تكون مفاجئة:

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

· في حالة إتلاف معلومات makepp حول ما حدث في الإصدار الأخير (على سبيل المثال ،
تحذف الدليل الفرعي ".makepp" ، أو لا تنسخه عند نسخ كل شيء
آخر) ، ثم يتم تشغيل إعادة البناء.

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

· إذا قمت بتعديل ملف خارج نطاق سيطرة makepp (على سبيل المثال ، يمكنك تشغيل ملف
أمر compilation بنفسك) ، فسيقوم makepp بإعادة إنشاء الملف في المرة القادمة. (لو
تريد تجنب ذلك ، تحقق من خيار سطر الأوامر "- لا تنشئ".)

يتم إعادة بناء الملفات المعمارية المستقلة عند التبديل إلى ملف مختلف
هندسة معمارية. هذه ليست مشكلة في العادة ، لأنها غالبًا لا تستغرق وقتًا طويلاً
لبناء. سبب تمييز جميع الملفات بالهندسة المعمارية ، بدلاً من
مجرد ملفات ثنائية ، هو أنه في كثير من الأحيان تكون ملفات ASCII معمارية-
متكل. على سبيل المثال ، لن يتم تجميع الإخراج من برنامج Solaris "lex"
Linux (أو على الأقل كان هذا صحيحًا في المرة الأخيرة التي جربته فيها).

بشكل ملموس ، لن يتم إعادة بناء الملف ، أو يمكن جلبه من المستودع أو البناء
cache ، إذا ظل إخراج الأمر التالي كما هو ، أي يطابق توقيعات
التبعيات:

mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP ، VAL} ملف S

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

يفضل استخدام طريقة "architecture_independent" من خلال تحديدها باستخدام امتداد
معدِّل ": build_check architecture_independent" لكل قاعدة تنتج
ملفات مستقلة عن العمارة. Makepp افتراضيا لا يفترض أبدا أن أي ملفات
العمارة المستقلة ، لأنه حتى .c يمكن أن تعتمد الملفات على العمارة. ل
على سبيل المثال ، لن يتم تجميع ناتج Solaris lex تحت Linux ، أو على الأقل
لن آخر مرة حاولت. لذلك يجب عليك تحديد طريقة فحص الإنشاء هذه يدويًا لـ
أي ملفات مستقلة عن العمارة حقًا.

بشكل ملموس ، لن يتم إعادة بناء الملف ، أو يمكن جلبه من المستودع أو البناء
cache ، إذا ظل إخراج الأمر التالي كما هو ، أي يطابق توقيعات
التبعيات:

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_ {DEP ، VAL} ملف S

التجاهل
طريقة "ignore_action" هي نفسها "بالضبط_المطابقة" باستثناء أنها لا تتحقق
سلسلة الإجراء (الأمر). في بعض الأحيان يمكن أن يتغير الأمر وأنت لا تريد ذلك
فرض إعادة البناء.

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

BUILD_DATE: = $ (تاريخ الصدفة)

my_program: $ (وحدات) .o
$ (CXX) $ (المدخلات) -DBUILD_DATE = "\" $ (BUILD_DATE) \ "" date_stamp.c -o $ (الإخراج)

هذا سوف يجمع تاريخ_طابع ج باستخدام طابع تاريخ الإنشاء الأخير ، ولكن لن يفرض ملف
إعادة التحويل البرمجي عندما يتغير التاريخ. لسوء الحظ ، إذا كان هناك شيء آخر عن الرابط
يتغير الأمر (على سبيل المثال ، يمكنك تغيير خيارات الرابط) ، كما أنه لن يؤدي إلى إعادة البناء.

هذا مفيد أيضًا بالاقتران مع $ (Changes_inputs) أو $؟ متغير ل
الإجراءات التي تقوم فقط بتحديث الهدف ، بدلاً من إعادة بنائه من الصفر. ل
على سبيل المثال ، يمكنك تحديث ملف .a مثل هذا:

libmine.a: * .o: build_check ignore_action
$ (AR) ru $ (output) $ (تغيرت المدخلات)

سيستمر هذا الإجراء في الغالب إذا نسيت تحديد ": build_check
ignore_action ". ومع ذلك ، افترض أنه لم يتغير أي من ملفات. o. الأمر
ستصبح الآن "ar ru libmine.a" والتي ربما تكون مختلفة عما كانت عليه في المرة السابقة
(على سبيل المثال ، "ar ru libmine.a buggy_module.o") ، لذلك سيقوم makepp بتشغيل الأمر. في هذا
الحالة ، لن يفعل الأمر أي شيء باستثناء إضاعة الوقت.

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

libmine.a: * .o
& rm $ (الإخراج)
$ (AR) ru $ (output) $ (input)

بشكل ملموس ، لن يتم إعادة بناء الملف ، أو يمكن جلبه من المستودع أو البناء
cache ، إذا ظل إخراج الأمر التالي كما هو ، أي يطابق توقيعات
التبعيات:

mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP ، VAL} ملف S

target_newer
طريقة "target_newer" تبحث فقط في تاريخ الملف. إذا كان أي تبعية أكثر
في الآونة الأخيرة من الهدف ، يتم إعادة بناء الهدف. هذه هي الخوارزمية التي يستخدمها ملف
نظام يونكس التقليدي جعل استخدامات المنفعة.

طريقة "target_newer" ليست آمنة مثل طريقة "بالضبط_المطابقة" لأنها لن تفعل ذلك
قم بتشغيل إعادة بناء إذا قمت بتغيير أمر البناء ، أو إذا قمت باستبدال ملف بامتداد
نسخة أقدم. في بعض الأحيان يمكن أن يتم الخلط أيضًا إذا كانت الساعات غير صحيحة
متزامن. على سبيل المثال ، إذا حصل الملف بطريقة ما على تاريخ 4 يونيو 2048 ، إذن
من الآن وحتى عام 2048 ، سيتم إعادة بناء كل ملف يعتمد على هذا الملف بالرغم من ذلك
الملف لا يتغير. كما أن التبديل إلى بنية مختلفة لن يؤدي إلى تشغيل ملف
إعادة بناء. يمنع جلب هدف القاعدة من ذاكرة التخزين المؤقت للبناء ، لأنه لا يوجد
توقيع فريد يمكن ربطه بمجموعة لا نهائية من الأزواج التي تفي بامتداد
علاقة أحدث من.

ولكن هناك بعض الحالات التي قد ترغب فيها في استخدام طريقة "target_newer":

· عندما يكون من المعقول أن يقوم المستخدم بإنشاء ملف خارج نطاق سيطرة makepp.
ربما يكون المثال الأكثر شيوعًا هو الأوامر التي تولد ملف makefile
نفسها ، أي إجراء التكوين التلقائي. يقوم المستخدمون عادة بإصدار تكوين
الأمر يدويًا ، ولكن غالبًا ما يكون لملفات makefiles طريقة لتحديث نفسها
تلقائيا. في هذه الحالة ، لا نريد إجبار makefile على إعادة البناء
نفسها إذا كتب المستخدم الأمر يدويًا ، لذا فإن طريقة "target_newer" هي
أكثر ملاءمة من طريقة "المطابقة الدقيقة". في الواقع ، إذا كان makepp يحاول
بناء ملف makefile ، فإنه يجعل "target_newer" الطريقة الافتراضية حتى تنتهي
بناء الملف.

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

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

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

$ (ROOT) / تضمين /٪. h:٪ .h
& ln -fr $ (إدخال) $ (إخراج)

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

٪ .list:٪ .x: build_check only_action
& صدى $ (المدخلات) -o $ (الإخراج)

بشكل ملموس ، لن يتم إعادة بناء الملف ، أو يمكن جلبه من المستودع أو البناء
cache ، إذا ظل إخراج الأمر التالي كما هو ، أي يطابق توقيعات
التبعيات:

ملف mppi -kCOMMAND

طرق أخرى للتحقق من البناء ممكنة. يمكنك كتابة طريقة فحص البناء الخاصة بك عن طريق
إنشاء وحدة نمطية "Mpp :: BuildCheck :: MyMethod". اقرأ الوثائق في
MPP / BuildCheck.pm في توزيع makepp. على الأرجح ، سوف ترغب في فحص البناء الخاص بك
طريقة ترث من "Mpp :: BuildCheck :: definitely_match" ، لذا اقرأ وثائقها أيضًا.

يعد تعديل آلية التوقيع مفيدًا أكثر من تعديل فحص الإنشاء
آلية مباشرة. قبل تغيير آلية فحص الإنشاء ، تحقق مما إذا كانت مشكلتك كذلك
يتم تقديمه بشكل أفضل عن طريق تغيير التوقيعات (انظر makepp_signatures للحصول على التفاصيل).

فيما يلي بعض الأسباب التي تجعل طريقة فحص الإنشاء المخصص مفيدة:

· إذا كنت تريد makepp لتجاهل جزء من الأمر. على سبيل المثال ، إذا كان لديك أوامر
في ملفك مثل هذا:

xo: xc
ssh $ (REMOTE_MACHINE) cc $ <-o $ @

قد تريد makepp عدم فرض إعادة بناء إذا تغير "$ (REMOTE_MACHINE)". أنت
يمكنه تعديل طريقة "selected_match" حتى يعرف أوامر ssh ويتجاهل
إسم الألة. تحقق: أرسل لطريقة أخرى لتحقيق ذلك.

استخدم makepp_build_check عبر الإنترنت باستخدام خدمات onworks.net