Ninja: لم يتم حل مسارات subninja النسبية

جميع المسارات مرتبطة بدليل الإنشاء ، وليس إلى الملف الذي يحتوي على سطر subninja.

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

ما ، إذن ، حالات الاستخدام المتناقضة لـ subninja مقابل include ؟

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

لن يتم تعديل وظيفة include ، وستعمل بالضبط كيف تتصرف subninjas بخلاف أسماء قواعد الحقيقة التي ستكون الآن في مساحة اسم مدمجة (وفقًا # 921). حاليًا ، يحقق subninja و include نفس الشيء بشكل أساسي بخلاف تحديد نطاق المتغيرات وأسماء القواعد ...

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

صحيح أن الفرق بين subninja و include هو أن الأول يضيف نطاقًا والأخير لا يضيف نطاقًا. حالة الاستخدام لهذا هو أن النينجا المستوى الأعلى يمكنه تحديد قواعد البناء الشائعة مثل cc التي تشير إلى متغيرات مثل cflags ، ويمكن لكل subninja تعيين cflags إلى ما هو مناسب لهذا الهدف ، وهناك يمكن أن تكون إجراءات لمرة واحدة هناك. لمشاهدة مثال ، يمكنك تشغيل python misc / write_fake_manifests.py / tmp / foo` لكتابة مجموعة من ملفات .ninja إلى / tmp / foo التي تستخدم هذا النمط.

هذا منطقي ، على الرغم من أنني ما زلت لا أرى الكثير من الفوائد (بخلاف النطاق).

من الممتع دمج ملفات النينجا التي تم إنشاؤها بواسطة مولدات مختلفة (يبدو أن هذا ما تريد القيام به؟)

بالضبط. القدرة على تضمين Ninja نفسها كوحدة فرعية للمولِّد الخاص بي ، ثم مشروع CMake آخر (تم تكوينه لإخراج ملفات إنشاء Ninja) ، ثم إنشاء ملفات تكوين Ninja لكليهما وتضمينهما كـ subninja s في _my_ project's build.ninja file لكي تكون قادرًا على بنائها كما لو كانت بمفردها ، ولكن مع السماح لمشروعي باستخدام مخرجاتها (وبالتالي الرسوم البيانية التبعية الخاصة بهم) من أجل بناء المشروع بأكمله مرة واحدة .

إذا كان ذلك منطقيًا. حالة الاستخدام الفوري التي أراها مع المولِّد الخاص بي على وجه الخصوص هي أنه يستعير بعض المفاهيم من Tup (التي أثرت IIRC في بعض قرارات التصميم داخل Ninja نفسها) حيث يمكنني تضمين N المشاريع الفرعية ، وكلها مع build.ninja الملفات ، ثم اضغط على الرسوم البيانية الخاصة بهم للسماح لي تلقائيًا بإنشاء رسم بياني أكبر بكثير للتبعية.

أنا شخصياً أعتقد أن هذا سيجعل subninja كليًا أكثر فائدة ، على الرغم من أنني يمكن أن أرى أنه تغيير محتمل. ومع ذلك ، لا أرى طريقة للتغلب على هذا إلا إذا 1) قمت بتعديل ملفات التبعيات ' build.ninja مع تصحيح أو 2) التضحية بالقدرة على تسخير الرسوم البيانية التبعية.

أفكار؟

ماذا عن:

subninja path/to/build.ninja relative path/to

وغياب relative هو ./ . هذا من شأنه أن يجعله غير قابل للكسر ولكنه لا يزال يعطي الوظيفة إذا رغب المولد في ذلك.

أو ، باتباع خطوات بنى النينجا الأخرى ، ربما

subninja path/to/build.ninja
  relative = path/to

افترض أن لديك مشروعًا في ... / foo ولديه شريط دليل فرعي ، وأن Ninja كان لديه منطق المسار النسبي الذي تقترحه.

إذا كان نظام البناء الخاص بك يريد كتابة جميع مخرجات البناء إلى / foo / obj ، فيجب أن يعرف subninja في / foo / bar الذي يستخدم المسارات النسبية للدليل لكتابة مخرجاته في ../obj/bar ، لأن هذا هو المسار إلى الملف من هذا الدليل الفرعي. لذا ، يجب أن يكون كل ما يُنشئ ملفات build.ninja على دراية بالتسلسل الهرمي للمسار العام ، وفي هذه الحالة يكون جعل جميع المسارات نسبيًا هو نفس المشكلة مثل تقديم شريط / إلى المسارات في الشريط / الدليل.

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

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

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

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

إيفان: الطريقة التي فهمت بها هذا هي أنك ستنشئ شجرة مثل هذه:

  subbuild1
  subbuild2

ونظرًا لأن المولدات عادةً ما تدعم وضع مسار البناء في أماكن عشوائية ، يجب أن يعمل مشروع البناء 1 في المبنى الفرعي 1 والمشروع 2 في المبنى الفرعي 2. ثم هناك ملف نينجا عالي المستوى في builddir يريد Qix- قيادة بناء المشاريع الفرعية.

غير مرتبط: يجب على هذه الميزة relative أيضًا تغيير cwd إلى وسيطتها إذا كانت أي قواعد تعتمد على أن الدليل الحالي مساوٍ لـ build dir (على سبيل المثال ، إذا كانت القاعدة تقطع القطع الأثرية المبنية أو شيء من هذا القبيل).