Ninja: إضافة خيار سطر أوامر ARGS لتمرير الوسائط إلى الهدف.

ألا يمكنك استخدام (cd $build_dir && ctest -R "FooTest") ؟ ما هي ميزة إشراك النينجا؟

Ups ، لم أكن أعلم أنه لا يوجد تغيير في الدليل تحت () . على أي حال ، اعتقدت أن تمرير أي ARGS إضافي

رائع ، يبدو أن حالة الاستخدام الخاصة بك قد تم تناولها ، لذا أغلق هذا الآن :-)

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

ninja -C out / debug use / module: test && out / debug / module_test --gtest_filter = test1

مع تمرير الحجج:

ninja -C out / debug use / module: run - --gtest_filter = test1

سيكون مفيدًا أيضًا إذا كان لدى النينجا طريقة لتمرير الإعداد -v. إلى البرامج النصية.

مع النينجا بشكل فعال كأمر الواجهة الأمامية لـ GN ،

هذه ليست فكرة جيدة إذا كنت تريد الكثير من الميزات وتحسينات جودة الحياة. النينجا صغير الحجم و "منخفض المستوى".

بالنسبة للاختبار: IMHO يكون أكثر شفافية إذا تم تمرير وسيطات اختبار الوحدة فقط إلى عداء الاختبار ، على سبيل المثال ، يمكنك استدعاء الثنائي مباشرة بنفسك. لنفترض أنك تريد إنهاء المكالمة بـ vallgrind ، كيف ستفعل ذلك مع Ninja؟ أو تريد أن ترى ناتجها أثناء إنشائها؟

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

ما أعنيه هو أن مستخدم GN يصدر عمومًا أوامر بناء فعلية من خلال النينجا ، مع استدعاء GN حسب الحاجة لإعادة إنشاء ملفات بناء النينجا عند تعديل ملفات البناء.

يمكنك ربط الأوامر في Bash بحيث يكون الثنائي محدثًا دائمًا:

ninja -C out/debug && ./out/debug/theTestBinary --gtest_filter=test1

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

آه لقد فهمت. هذا أمر مؤسف حقًا ، ولكن نظرًا لأن المولد يعرف هذا أيضًا ، أعتقد أنه يجب أن يكون هو الشخص الذي يوفر الاختصارات / الواجهة الأمامية. يقوم CMake بهذا باستخدام cmake --build و ctest ، ربما يجب أن يكون GN أيضًا.

مع النينجا بشكل فعال كأمر الواجهة الأمامية لـ GN

ما هو GN؟

ما هو GN؟
https://gn.googlesource.com/gn/

GN هو نظام بناء التعريف لـ Chromium الذي يستهدف النينجا. إنه نظام بناء رائع ولكنه غير معروف جيدًا. التقط مثالك:

أداة ninja -C out / debug

كما ذكرت ، لدى GN نينجا يقوم بالبنى الفعلية ، مع استدعاء GN حسب الحاجة عند تغيير تعريفات البناء. لذلك إذا دعم النينجا إعادة توجيه الحجج ، فقد ينتج عن ذلك أمر أبسط للمستخدمين لأن النينجا لديه بالفعل دليل إخراج (خارج / تصحيح) ، الهدف (عنصر واجهة مستخدم: اختبار) ، ويمكنه إجراء الاختبار أيضًا إذا كان إعادة التوجيه ممكنًا:

أداة ninja -C out / debug

خيار آخر هو المرور عبر البيئة ، مثل

rule whatever
  command = theTestBinary $$ARGS

وثم

$ ARGS="-foo bar" ninja ...

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