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

برنامج:

اسم

makepp_sandboxes - كيفية تقسيم بنية makepp

الوصف

D: - افعل البناء ،
--لا تبني،
--لا تقرأ ،
- هل تقرأ ، I: - في رمل ،
- صندوق رمل داخلي ، O: - خارج الصندوق ، S: - ساندبوكس ،
- Sandbox-warn ،
--تحذير من وضع الحماية، V: - وضع الحماية الافتراضي

هناك عدة أسباب قد تدفعك إلى تقسيم شجرة الملفات لإجراء makepp
بناء:

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

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

لدى Makepp مرافق وضع الحماية التي تعالج كلا الاهتمامين.

وضع الحماية مزيد من الخيارات
يمكن استخدام خيارات makepp التالية لتعيين خصائص وضع الحماية للشجرة الفرعية
معطى بواسطة مسار وجميع ملفاته وملفاته المحتملة:

--لا تقم بالبناء مسار
--do-build مسار
قم بتعيين أو إعادة تعيين خاصية "عدم الإنشاء". من المفترض أن يكون أي ملف يحتوي على مجموعة الخصائص هذه
أن يكون محدثًا بالفعل، ولن يتم إجراء أي عمليات فحص للإنشاء. تتم إعادة تعيين الإعداد الافتراضي
(أي "القيام بالبناء")، إلا إذا كان لديك "RootMakeppfile"، وفي هذه الحالة كل شيء
خارج معرف الشجرة الفرعية الخاص بها "لا تقم بالبناء".

- ساندبوكس مسار
--في رمل مسار
--داخل الرمل مسار
--خارج نطاق الحماية مسار
قم بتعيين أو إعادة تعيين خاصية "in-sandbox". يظهر خطأ إذا كان makepp سيغير ذلك
إرسال ملف مع إعادة تعيين هذه الخاصية. لا يزال يتم تنفيذ عمليات التحقق من البناء، ما لم
تم أيضًا تعيين خاصية "عدم البناء". تم تعيين الإعداد الافتراضي (أي "في وضع الحماية")، ما لم
هناك أي - ساندبوكس الخيارات، وفي هذه الحالة يكون الخيار الافتراضي لجميع الملفات الأخرى
إعادة التعيين (أي "خارج نطاق الحماية").

- ساندبوكس-تحذير
--sandbox-تحذير
الرجوع إلى إصدار سابق من انتهاكات "in-sandbox" و "dont-read" إلى التحذيرات بدلاً من الأخطاء.
وهذا مفيد عندما يكون هناك مئات الانتهاكات، بحيث يمكنك جمعها كلها
لهم في جولة واحدة واتخاذ الإجراءات التصحيحية المناسبة. وإلا فإنك ترى فقط
انتهاك واحد لكل استدعاء makepp، ولا تعرف عدد المخالفات المتبقية حتى
انهم جميعا ثابتة.

--لا تقرأ مسار
--اقرأ مسار
قم بتعيين أو إعادة تعيين خاصية "عدم القراءة". يظهر خطأ إذا كان makepp سيغير ذلك
قراءة ملف مع مجموعة الخصائص هذه. تتم إعادة تعيين الإعداد الافتراضي (أي "اقرأ").

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

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

إذا تم تعيين خاصية ما وإعادة تعيينها على نفس المسار بالضبط، فسيظهر الخيار
الأبعد إلى اليمين في سطر الأوامر له الأسبقية.

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

إلى حد بعيد الحالة الأكثر شيوعًا لمثل هذا التحسين هي أنك تعلم أن كل شيء ليس كذلك
في أو أسفل دليل البداية تم تحديثه بالفعل. يمكن إبلاغ هذا إلى
makepp باستخدام "--لا تقم بالبناء /. --do-build .".

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

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

· -j لا يتوازى حاليًا مع بعض مهام makepp التي تستغرق وقتًا طويلاً مثل التحميل
makefiles، والمسح، وبناء التبعيات الضمنية أثناء المسح، والتحقق
التبعيات.

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

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

بالإضافة إلى ذلك، تحدد كل عملية صناديق الحماية لأي عمليات أخرى قد تكون متزامنة
كـ "لا تقرأ". إذا قرأت إحدى العمليات ملفًا، فإن العملية المتزامنة الأخرى تكون مسؤولة
للكتابة (والتي قد لا تكون مكتوبة بعد)، ثم ينشأ خطأ
على الفور.

وضع الحماية For تسلسلي العمليات
عندما يتم تقسيم البنية لعمليات makepp المتزامنة، عادةً ما يكون هناك أيضًا ملف
العلاقة التسلسلية بين أزواج مختلفة من العمليات. على سبيل المثال، قد يكون هناك
عشرات من عمليات الترجمة المتزامنة، تليها عملية ربط واحدة لا يمكن أن تبدأ
حتى تكتمل جميع عمليات التجميع. يجب أن تكون مثل هذه العلاقات المتسلسلة
يتم فرضه بواسطة أي آلية تقوم بتنسيق عمليات makepp المختلفة (على سبيل المثال،
نظام قائمة انتظار الوظائف).

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

ومع ذلك، فمن المفيد عمومًا التحديد --لا تقم بالبناء خيارات للمعتمد
العملية (عملية الارتباط في مثالنا) التي تُعلمها بالمناطق الموجودة بالفعل
تم تحديثه من خلال العمليات المطلوبة مسبقًا (وظائف الترجمة في مثالنا). في هذا
بطريقة ما، فإننا نتجنب معظم العمل غير الضروري لأهداف البناء الفارغة التي كانت عادلة
محدث.

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