Ninja: دعم تحديد الإسهاب من خلال البيئة

تم إنشاؤها على ٢٨ ديسمبر ٢٠١٧  ·  14تعليقات  ·  مصدر: ninja-build/ninja

في بعض الأحيان ، للأسف ، يعد استخدام البيئة أنظف طريقة لتهيئة التطبيقات.

على سبيل المثال MAKEFLAGS و DISTCC_HOSTS وما إلى ذلك.

سيكون من المفيد أن يتحكم المرء في إسهاب النينجا من خلال البيئة.

على سبيل المثال لديك

عنكبوت = 1 نينجا

يكون (تقريبًا) مكافئًا لـ

النينجا الخامس

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

التعليق الأكثر فائدة

ليس لدي هذا الدليل على جهاز لينكس الخاص بي ، على ما يبدو.

لا يمكنني العثور على مرجع له في معيار التسلسل الهرمي لنظام الملفات http://www.pathname.com/fhs/pub/fhs-2.3.pdf

لقد وجدت إشارة إلى / usr / local / sbin في FHS على الرغم من ذلك ، ربما هذا ما قصدته؟ يبدو من الغريب استخدام مجلد "sbin" لهذا الغرض.

من المفترض أن / usr / local / bin من المفترض أن يكون على المسار قبل / usr / bin وغيرها.

ومع ذلك ، هذا ليس ما قلته. قال لك هذا:

في هذه الحالة يمكنك تجنب تعديل PATH عن طريق إعادة تسمية ثنائي النينجا ووضع البرنامج النصي في مكانه.

وهذا اقتراح سيء مليء بالأمان ومشاكل الصيانة المستمرة.

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

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

ال 14 كومينتر

أعتقد أنه في مثل هذه الحالات ، يمكنك إنشاء نص برمجي للالتزام بمتغيرات البيئة الخاصة بك. وإلا يمكنني التفكير في بيئات مكافئة حيث يريد شخص ما VERBOSE = 1 للتحكم في إسهاب برنامج آخر غير Ninja.

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

متغيرات البيئة هذه مخصصة للنينجا ، فكيف سيتم إطاعتها إذا لم يتعرف عليها النينجا؟

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

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

متغيرات البيئة هذه مخصصة للنينجا ، فكيف سيتم إطاعتها إذا لم يتعرف عليها النينجا؟

سيتعرف عليهم البرنامج النصي ويمرر على سبيل المثال -v إلى النينجا.

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

لا، ما عليك سوى سيناريو واحد للقيام بذلك، والتي سمها ninja ووضعها في حياتك PATH قبل exectuable النينجا الحقيقية.

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

هذا أيضًا غير معقول لأنه يبدأ الآن في التأثير على خطوط أنابيب إنشاء التكاثر حيث يكون من الممكن تتبع البيئات.

سيكون لديك النص الخاص بك دائمًا هناك ، ثم يمكنك تتبع VERBOSE تمامًا كما تفعل إذا تعامل النينجا نفسه معه.

أعتقد أنه آمن PATH

ماذا تقصد بذلك؟

لست مهتمًا بـ VERBOSE ، أعتقد أن الاقتراحات الأخرى لكشف العلامات عبر NINJAFLAGS أكثر ملاءمة كما هو مقترح في العديد من القضايا الأخرى حول هذا الموضوع.

مرة أخرى ، هذا طلب غير معقول عندما تدير مئات الحزم ، بعضها يستخدم cmake لإنشاء سكربتات بناء النينجا. إن إنشاء غلاف غير ضروري ليكون بمثابة تبعية يتم بشكل مفرط عندما تستمر الأنظمة التقليدية مثل make (مع إنشاء أو كتابة Makefile s) في تكريم ليس فقط البيئات الواقعية مثل CFLAGS ، CXXFLAGS ، LDFLAGS ، إلخ. ولكن أيضًا MAKEFLAGS حيث يقوم الكثير منا بتعيين شيء ما لتأثير -j$(nproc) .

يأتي هذا مرة أخرى إلى فكرة المسار الآمن ؛ ستعمل أنظمة مثل sudo و build / CI scripts على تعيين PATH إلى قيمة افتراضية جيدة معروفة لتجنب أي تلوث محتمل للبناء مدعومًا أيضًا بـ chroot نظيف.

بعضها يستخدم cmake لتوليد نصوص بناء النينجا.

لا أرى كيف يغير هذا أي شيء؟

يأتي هذا مرة أخرى إلى فكرة المسار الآمن ؛ ستعمل أنظمة مثل sudo و build / CI scripts على تعيين PATH على قيمة افتراضية جيدة معروفة لتجنب أي تلوث محتمل للبناء مدعومًا أيضًا بـ chroot نظيف.

في هذه الحالة يمكنك تجنب تعديل PATH بإعادة تسمية ثنائي النينجا ووضع البرنامج النصي في مكانه.

ومن حولنا نذهب

في هذه الحالة يمكنك تجنب تعديل PATH عن طريق إعادة تسمية ثنائي النينجا ووضع البرنامج النصي في مكانه.

هذا غير مناسب للإيحاء

يجب ألا يتخبط المستخدمون

ليس من المناسب لنظام متعدد المستخدمين أن تتم إعادة تسمية الملف الثنائي على مستوى النظام واستبداله بنص.

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

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

ما يمكنني قبوله: يستجيب Ninja للعديد من متغيرات البيئة.

ما هو غير مقبول: الحاجة إلى كتابة برنامج نصي مجمّع.

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

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

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

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

لا ، عند النشر إلى Linux ، أقترح وضع البرنامج النصي في /usr/local/bin .

ليس لدي هذا الدليل على جهاز لينكس الخاص بي ، على ما يبدو.

لا يمكنني العثور على مرجع له في معيار التسلسل الهرمي لنظام الملفات http://www.pathname.com/fhs/pub/fhs-2.3.pdf

لقد وجدت إشارة إلى / usr / local / sbin في FHS على الرغم من ذلك ، ربما هذا ما قصدته؟ يبدو من الغريب استخدام مجلد "sbin" لهذا الغرض.

من المفترض أن / usr / local / bin من المفترض أن يكون على المسار قبل / usr / bin وغيرها.

ومع ذلك ، هذا ليس ما قلته. قال لك هذا:

في هذه الحالة يمكنك تجنب تعديل PATH عن طريق إعادة تسمية ثنائي النينجا ووضع البرنامج النصي في مكانه.

وهذا اقتراح سيء مليء بالأمان ومشاكل الصيانة المستمرة.

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

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

تدعم إعادة تطبيق لغة Ninja المستقلة https://github.com/michaelforney/samurai ذلك عبر متغير البيئة SAMUFLAGS. ما عليك سوى استخدام samu في أي مكان كنت تستخدم فيه النينجا بطريقة أخرى ، أو قم بتثبيت samu كنظام / usr / bin / ninja (بعض توزيعات لينكس لديها خيارات لتثبيت هذا التطبيق المتنافس باعتباره النينجا الافتراضي ، أو النينجا فقط).

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات