Godot: ضع في اعتبارك نقل نظام البناء إلى Meson أو نظام بناء آخر

من أجل ما أفهمه ، يجب أن توفر أدوات نظام البناء:

• تجميع متقاطع (تجميع لكل منصة مستهدفة ممكنة من نفس النظام الأساسي المضيف).
  
  
  
  • أعني بكلمة "ممكن" أن المضيف يسمح بذلك (لذا فإن macOS و iOS ممكنان فقط في جهاز Mac ، ومن Linux مع OSXCross).
  
  
• طريقة لإنشاء الملفات (الترجمة من PO ، فئات shader من GLSL ، بيانات التوثيق من XML).
  
  
  
  • تعرف SCons أن الملفات التي تم إنشاؤها هي تبعيات ، لذا فإن تغييرها يؤدي إلى إعادة بناء الملفات ذات الصلة. هذا يجب ان يؤخذ بعين الاعتبار ايضا
  
  
• أهداف وخيارات متعددة ضمن الأهداف (الهدف = التصحيح / الإصدار_الشطب / الإصدار ، الهندسة المعمارية مثل x86 أو ARM ، 32 أو 64 بت).
• خيارات لتخصيص أهداف الإنشاء / التمكين الإضافية (غلاف gdnative ، بدون غراء أحادي ، تمكين / تعطيل: الوحدات النمطية ، وبرامج التشغيل ، والميزات المهملة ، وما إلى ذلك ، قم بتعيين libs للتجميع الثابت باستخدام الكود المدمج أو استخدام libs للنظام ، لكل منها واحد على حدة).

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

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

أعتقد أن مثل هذا إثبات المفهوم سيكون ذا قيمة كبيرة لأنه

• يعطينا فكرة أفضل إذا كان نظام البناء الجديد يتعامل مع كل ما نحتاجه ومدى نجاحه
• إنه يعطينا بيانات محددة بدلاً من بيانات مجردة للمناقشة

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

-

الآن ، شخصيًا ، يجب أن أقول إنني لست مع هذا الأمر ولا ضده ، لكنني أعتقد أن هناك المزيد من الفاكهة المعلقة لمطاردتها بدلاً من (أو قبل ذلك؟) تغيير نظام البناء بأكمله. خاصة في هذه المرحلة الزمنية الحرجة ، حيث تكون هناك حاجة إلى أكبر عدد ممكن من الأيدي للتأكد من أن الإصدار 3.0 والتصحيحات الأولى في أفضل شكل ممكن. ولكن إذا أردنا تحسين نظام البناء ، فسوف ألقي نظرة على أوقات بناء CI ومتاعب وضع Mono build. (أعتقد أن هذه هي على akien الصورة TODO / قائمة aggrievances؟)

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

TL ؛ DR:

• أوافق على عدم وجود وثائق / موارد SCons ، حيث أن نصوص البناء سهلة ، حيث تتعارض Python إلى حد ما مع ذلك ، IMO
• كمساهم جديد ، كان نظام بناء Godot واحدًا من أقل الأنظمة إزعاجًا للإعداد ، وهو وقت قليل جدًا لأول تجميع ناجح
• أفضل أن أرى الجهد المبذول لتحسين 3.0 / 3.1 قدر الإمكان وربما أفكر في هذا بمجرد استقرارها
• قد تكون أوقات إنشاء CI الأفضل وتصاميم Mono الأسهل أكثر أهمية

آرائي. :)

أعتقد تمامًا أن الحصول على 3.0 والتركيز على الإصدارات التالية (3.0.1 ، 3.1) يجب أن يكون له الأولوية على هذا ، للتسجيل.
أنا أعرف لماذا الناس لا يحبون العمل على buildsystems (لأنه حقا فقط لصالح المطورين الآخرين / خاصة للمستخدمين النهائيين البارعين في امور التكنولوجيا - وهي ليست الامم المتحدة أهمية، أنه من المفيد لجعل حياة المشروعات الإنمائية "والمساهمين" أسهل ، ولكن في النهاية تكون سعادة المستخدمين النهائيين هي الهدف) وهناك شيء "تكلفة الفرصة البديلة" بالكامل ، أي. عندما يتم إنفاق الوقت (أو الضياع / الضائع ، اعتمادًا على من تسأل) في تحسين نظام البناء ، يمكن إنفاقه على تحسين المشروع نفسه. (ما لم تكن مثلي ولا يمكنك العمل حقًا في جانب C ++ للأشياء على أي حال.)

وفي النهاية ، تعمل SCons حقًا "فقط" والتي من المحتمل أن تكون جيدة بما فيه الكفاية بالنسبة لمعظم المطورين ، لذلك في حين أن هذا شيء آمل أن يحدث في النهاية ، فأنا لا أحبس أنفاسي من أجل 3.1 أو حتى 3.2 ، حتى إذا حصل على دعم كافٍ حتى ينتهي به الأمر في الواقع إلى أن يبدأ العمل به.

كل هذا قيل ، قد أبدأ POC في وقت لاحق من هذا الأسبوع في مفترقتي ، لأولئك الذين هم على استعداد لمتابعة التقدم في ذلك (ومن المحتمل أن يساعدوني ، لأنني لا أمتلك قدرًا كبيرًا من الخبرة في كتابة أنظمة البناء) ، لكنني لن أفتح طلب سحب لهذا لفترة من الوقت على الأرجح.

لا أجد حقًا أن SCons بطيئة ، وربما لا مثيل لها في مرونتها (التي نستفيد منها كثيرًا). لقد أثبتت SCons أيضًا أنها أثبتت جدواها ، وأجد أنها لا تفسد البناء أبدًا.

بصراحة ، ما لم يتطوع شخص ما لإعادة كتابة نظام البناء بالكامل (وليس مجرد إثبات للمفهوم) ، وأظهر أنه إما أبسط (رمز أقل بكثير ) أو

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

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

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

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

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

لا أعرف ما إذا كان Meson سيكون أسرع بشكل ملحوظ ، ولكن إذا كان شخص ما على استعداد للمحاولة ، فأنا لست ضد ذلك.

بالتأكيد ، إذا أخذ شخص ما الوقت الكافي للقيام بذلك وأظهر أنه تحسن كبير بما يكفي لتبرير التبديل ، فأنا جميعًا مع ذلك :)

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

أفترض أن هذا يمنحني (و / أو أي شخص آخر يعمل على هذا في المستقبل) هدفًا نظيفًا ذا شقين للوصول إليه:

• احصل على جودو ليترجم مع ميزون بأي شكل لتبدأ به
• اجعل الأمر سهلاً مثل SCons في الوقت الحالي ، وربما أكثر من ذلك (عن طريق تحسين السرعات)

وأفترض أن سرعة SCons ليست رهيبة (الجزء الأكبر من وقت عملية الإنشاء يكون من الارتباط الفعلي والتجميع على أي حال ، لذا من المحتمل أن يكون التباطؤ من الحمل العلوي لنظام البناء ضئيلًا إلى حد ما) ، لكنه بالتأكيد يمكن تحسينه ، وتقديم Meson كبديل قد يكون مجرد تحسين. سوف نرى.

ربما تكون المشكلة الأكبر هي استبدال البرامج النصية لإنشاء Python لتوليد الكود تلقائيًا مثل التظليل ، ولا يبدو أن ميزون لديه ميزة من هذا القبيل.

وتقديم Meson كبديل قد يكون مجرد تحسين. سوف نرى.

لا ينبغي أن يكون بديلاً ، إما أن ننتقل إليه إذا كان من الواضح أنه أفضل ، أو حتى أننا لا نقدمه. الاضطرار إلى دعم نظامي بناء أمر مجنون.

صحيح ، هذا عادل.

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

سأبلغ مرة أخرى إذا حصلت على أي شيء حسن المظهر (مثل معيار).

على الرغم من أنني ، ليس ميزون ، سأقوم بإجراء اختبار في الأسابيع القادمة لمعرفة ما يلزم لبناء godot تحت bazel لنظام التشغيل windows 64 بت تحت msvc.

Bazel هو نظام آخر يتميز بوصف أقصر للبنية وبناء أسرع. كما أنها تحتفظ بها Google لذا فهي لن تذهب إلى أي مكان.

على أي حال ، لا يمكنني التحقق من ذلك ، ولكن من المحتمل جدًا أن يتم إنفاق 99٪ من الوقت الحسابي الذي يقضيه لبناء Godot في المترجم. لذا ، حتى لو لم يكن الحمل الزائد لبرمجيات البناء لا شيء ، فسيؤدي ذلك إلى تقليل وقت الإنشاء بنسبة 1٪. حتى التخفيض بنسبة 5٪ لن يكون ذا قيمة ، ما لم يسمح برمز أقل وموثوقية أكبر (أو إذا ثبت أنني مخطئ :)).

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

كما قلت من قبل ، فإن SCons بطيئة في البدء (تستغرق بضع ثوانٍ قبل أن تبدأ بالفعل في التجميع). إذا كنت تقوم ببناء المصدر بالكامل الذي لا يكاد يذكر ، ولكن إذا قمت فقط بتغيير سطر وتقوم بالتجميع للاختبار ، فيمكن أن يؤدي ذلك إلى تحسين سير العمل بشكل كبير (ما هو IMO الأكثر أهمية في نظام البناء: مساعدة الأشخاص الذين يعملون مع الكود) . لذا فإن انخفاض 5s في 10min بناء غير ذي صلة ، ولكن 5s انخفض في 10s إعادة البناء هو تحسن كبير.

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

Bazel هو نظام آخر يتميز بوصف أقصر للبنية وبناء أسرع. كما أنها تحتفظ بها Google لذا فهي لن تذهب إلى أي مكان.

حتى أن هناك فئة متزايدة من ويكيبيديا من "الأشياء التي توقف Google عن إنتاجها". :)

mhilbrunner كلا ، لا يزال يتم صيانته https://github.com/bazelbuild/bazel

كانت وجهة نظرهم أنه لمجرد أن Google نجحت في ذلك ، لا يعني ذلك أنها ستظل موجودة لفترة طويلة.

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

نظرًا لأننا احتضنا C # لتطوير اللعبة ، فقد نجرب أيضًا شيئًا مثل Cake .

لست متأكدًا مما إذا كانت المطالبة بتثبيت Mono لتجميع Godot فكرة جيدة ، مع الأخذ في الاعتبار أن Godot هو في الغالب مشروع C ++ ويمكن تجميعه بدون دعم C #.

يجب أن يكون مستوى الأداء المقدم من Meson أو CMake (مع مولد Ninja) أكثر من كافٍ لأغراض Godot.

Calinou ، ربما تكون على حق ، على الرغم من أنه يبدو أن الجميع قد قفز إلى عربة C # ، فأنا شخصياً أستخدمها لبرمجة الألعاب مع Godot وتطبيقات الإنتاجية مع Xamarin ، وأشكال ، أيضًا إذا كنت أرغب حقًا في الضغط على الأداء ، يمكنني تجربة شيء مثل محول IL2cpp أو الانتقال مباشرة إلى C ++. أفكر أيضًا في استخدام mono / csharp REPL و ASP.net للأشياء التي أستخدمها عادةً JavaScript أو Python أو PHP ، مثل الأشياء المتعلقة بتطوير الويب أو البرمجة النصية للقذيفة. الشيء هو أنني لا أمانع في امتلاك نظام بناء يعتمد على C # أيضًا ، لأنني كنت أستخدمه بالفعل في كل شيء تقريبًا. على الأقل بالنسبة لي ، ستكون نهاية "اللعنة ... لغة أخرى أحتاج إلى تعلمها ... لماذا لا يلتزمون بـ C ++ و -إدراج لغة ديناميكية / مُدارة لائقة هنا-"

يحرر:

للتوضيح ، فإن طلب تثبيت Mono Framework من أجل بناء Godot لا يبدو سيئًا بالنسبة لي ، لأن ما يسمى بمحركات ألعاب AAA تتطلب مساحة أكبر على القرص:

• جودو <50 ميغا بايت
• Godot مع دعم أحادي (<50 ميجابايت) + إطار أحادي (~ 350 ميجابايت) = 400 ميجابايت تقريبًا
• غير واقعي ~ 20 جيجا بايت
• الوحدة ~ 10 جيجابايت
• محرك CryEngine ~ 8 جيجابايت

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

أنا أحب CMake ، و meson يبدو رائعًا ، لكني أميل إلى الموافقة على هذا المقال: http://www.rojtberg.net/1481/do-not-use-meson.

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

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

ما أنشره في هذا الموضوع هو ، إذا تم تنفيذ الإجراء ، فهل سيتم النظر في طلب السحب للدمج؟

سيتم النظر فيها ، ولكن يجب أن تكون مفيدة على SCons.

بمجرد أن تفكر في CMake مجرد نظام بناء آخر وليس معيار الأمر الواقع ، ينتهي بك الأمر مع الكثير من الخيارات. لماذا ميزون عبر SCons؟ أو bazel / buck هي أدوات جيدة أيضًا؟ لكن أكبر حجة لدي لصالح CMake هي الأدوات المصممة لدعم هذا النظام البيئي. قواعد بيانات تجميع Clang ، ودعم الحزم لأنظمة تشغيل متعددة ، وما إلى ذلك. الجوانب السلبية الوحيدة الصالحة التي سمعتها هي بناء الجملة والمستندات السيئة ، لكن هذا ليس قويًا بما يكفي بالنسبة لي لتغيير موقفي من هذا.

لماذا ميزون عبر SCons؟

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

أو bazel / buck هي أدوات جيدة أيضًا؟

بالنظر إلى أن كل من bazel و buck مكتوبان بلغة Java (لا يمتلك godot التبعية إلا إذا كنت تستهدف android ، وحتى بعد ذلك يمكن للمرء استخدام NDK تقنيًا فقط ) ، فإنني أزعم أنهما على حق كاعتماد أساسي للجميع المستخدمين. Python موجود بالفعل في قائمة التبعية ، ويمكنك بسهولة تثبيت ميزون (ونينجا) من خلال pip install meson سريع

قواعد بيانات تجميع كلانج

يدعم Meson هذا افتراضيًا ، لأن هذه ميزة افتراضية مضمنة في النينجا

دعم للتعبئة لأنظمة تشغيل متعددة

يدعم Meson أيضًا هذا ، ويعتمد بشكل كبير على pkg-config عند الاقتضاء

الجوانب السلبية الوحيدة التي سمعتها هي بناء الجملة والمستندات السيئة

الميزون له بناء جملة يشبه بيثون ، يعتمد على المتغيرات والكائنات والوظائف المدمجة. في رأيي ، الكتابة

my_meson_list = ['x', 'y', 'z']
message(my_meson_list)

ضد

set(MY_CMAKE_LIST "x;y;z")
message(STATUS ${MY_CMAKE_LIST})

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

# In one file
set(USE_STD_CXX11 "-std=c++11")
set(USE_STDLIB_LIBCXX "-stdlib=libc++")

# Possibly elsewhere
set(LIBCXX $<BOOL:${CAN_USE_STDLIB_LIBCXX}>,$<BOOL:${BUILD_WITH_LIBCXX}>)
set(NO_RTTI $<BOOL:${CAN_USE_NO_RTTI}>,$<BOOL:${DISABLE_RTTI}>)

# Later on...
target_compile_options(my-exe
  PUBLIC
  $<$<BOOL:${CAN_USE_STD_CXX11}>:${USE_STD_CXX11}>
  $<$<AND:${LIBCXX}>:${USE_STDLIB_LIBCXX}>
  $<$<AND:${NO_RTTI}>:${USE_NO_RTTI}>
  # Oh yeah, you're gonna want more of these, because you can't trust compiler interfaces
)

# Generator expressions mean you can't follow the flow of the build to see what is called and defined where. This is a completely valid use of CMake.
check_cxx_compiler_flag(${USE_STDLIB_LIBCXX} CAN_USE_STDLIB_LIBCXX)
check_cxx_compiler_flag(${USE_NO_RTTI} CAN_USE_NO_RTTI)

يشبه الميزون المكافئ:

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

أعتقد أنني يجب أن أشير ، بالمناسبة ، إلى أنه من بين جميع أنظمة بناء C ++ الموجودة هناك ، فإن Meson هو الأقل فظاعة . تميل الحجج ضد استخدامه إلى أن تكون صورة لكوميديا ​​على شبكة الإنترنت ، وبعض الأيدي تلوح حول كيفية استخدام CMake ، لذلك يجب عليك فقط التعامل معها ، و "على الأقل CMake ليست أدوات آلية".

ولكن قبل كل شيء (وأعتقد أن هذا أمر مهم حقًا ، خاصة بالنسبة لأولئك الذين يستخدمون godot كما هو الحال مع gdnative) ، يدعم Meson الرؤوس المجمعة مسبقًا أصليًا. CMake لا (واستخدام cotire لاختراق البناء يمكن أن يسبب مشاكل أكثر من قيمتها).

لا يمكنني إخبارك إلى أي مدى يمكن أن يؤدي ذلك إلى تسريع عملية الإنشاء لمستخدمي gdnative ، ولكنه سيكون بمثابة زيادة كبيرة في دول مجلس التعاون الخليجي و msvc (على الأقل ، لا مفر من زيادة الأداء في msvc). أضف استخدام extern template للكميات الضئيلة جدًا من الشفرات النموذجية الموجودة في godot ، ويمكنك أن ترى تحسينات مناسبة لوقت البناء ، والتي تعد مهمة للبنيات التكرارية والإضافية.

يقوم Meson بإنشاء ملفات نينجا ، وهي أسرع بكثير للتطوير التدريجي.

لاحظ أن CMake يمكنه أيضًا إنشاء ملفات بناء Ninja بدلاً من Makefiles التقليدية ؛ يتم ذلك بتمرير -G Ninja إلى سطر الأوامر الخاص به. إنه يعمل بشكل جيد في معظم المشاريع التي جربتها وهو أسرع قليلاً بشكل عام (بالإضافة إلى أنه سيستخدم جميع مؤشرات ترابط وحدة المعالجة المركزية بشكل افتراضي).

لا يزال Meson يفوز في مقارنات الأداء الأولية التي رأيتها ، لكن هذا يساعد بالتأكيد على سد الفجوة بين أداء Meson و CMake.

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

حسنًا ، هذا دقيق تمامًا! أنا سعيد لأن لديك فكرة جيدة عن الميزات التي تقدرها في نظام البناء. ما زلت أعتقد أنه يجب أن يكون هناك نظام بناء قياسي في عالم C ++ يمكن للمشاريع الاعتماد عليه. أتمنى أن يكون الميزون عبارة عن ناقل CMake بدلاً من الشيء الخاص به.

ما زلت أعتقد أنه يجب أن يكون هناك نظام بناء قياسي في عالم C ++ يمكن للمشاريع الاعتماد عليه.

صدقني ، لا أحد يريد هذا أكثر مني. لقد أصبحت نوعًا من عفريت مهملات نظام البناء وحتى أنني قدمت حديثًا عنها في CppCon. أنا لسوء الحظ (أو لحسن الحظ؟) أهتم كثيرًا بأنظمة البناء ، إلى درجة الهوس تقريبًا. :)

أريد فقط أن أقول هذا ، لكن في كل مرة أقوم فيها ببناء طويل من Godot على Windows ، لاحظت أن Python استحوذ باستمرار على> 15٪ من وحدة المعالجة المركزية الخاصة بي. أشك في أنها بطيئة في البدء.

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

يجب أن يكون بناء godot ثنائي الأبعاد فقط كافيًا للاختبار مع تعطيل جميع الخيارات.

كان الحاجز الأول الذي واجهته هو core / make_binders.py. هذا هو الكود المُنشأ تلقائيًا الذي يستخدمه جودو.

لقد صنعت نموذجًا أوليًا في نظام البناء Bazel لكنني سأناقش الإعداد في مسألة أخرى. https://github.com/godotengine/godot/issues/18518

ليس لديك وقت على مدار الأسبوع ، ولكن يمكن للآخرين التوسع في Bazel BUILD.

لول كيف انخرط بازيل؟

نظرًا لأنه قد تكون هناك فرصة لمرة واحدة للتبديل إلى نظام بناء مختلف ، ألا يجب أن نبحث عن أفضل الخيارات الممكنة؟ أنا مهتم برؤية مخطط مقارنة Cake vs Bazel و Scons ، على الرغم من أنني يجب أن أعترف أنه ليس لدي أي خبرة مع Cake للقيام بعمل القدمين لتلك الاختبارات.

rraallvv تقصد كعكة أو CMake؟

isaachier يا سيئة ، كنت أتحدث عن www.cakebuild.net ، كان يجب أن أكون أكثر تحديدًا ، آسف لذلك.

أليس هذا فقط لـ C #؟

isaachier لا أعرف حقًا ، طوال هذا الوقت كنت أفترض أن Cake قادرة على ذلك ، تمامًا مثل SCons المكتوبة بلغة Python ولديها دعم لـ C ++. ومع ذلك ، سألت للتو في محادثتهم الجذابة ،

rraallvv للسجل أعتقد أن فكرة المقارنة جنبًا إلى جنب لأنظمة البناء الرئيسية فكرة رائعة. إليك ما وجدته عبر الإنترنت وأعتقد أنه غير متحيز إلى حد ما (لم يكتبه مطورو نظام الإنشاء): https://carlosvin.github.io/posts/choosing-modern-cpp-stack ، https: //www.reddit. com / r / cpp / comments / 6euc7b / build_systems_bazel_buck / die6g1y / https://stackoverflow.com/a/12022652/1930331.

رأيي الشخصي:

• CMake : لغة قبيحة جدًا ، لكنها منتشرة في كل مكان وهي من الناحية العملية معيار الصناعة.
• SCons : حالة بطيئة وقديمة وحالة IDK. يستخدم بايثون.
• الميزون : نظام بناء جديد ورائع يعتمد على Python وهو ليس بطيئًا بشكل لا يصدق. العيب الرئيسي هو المسار. من غير الواضح ما إذا كان هذا سيكون مجرد نكهة أخرى لنظام بناء الأسبوع.
• Autotools : قديم ، لا يوجد دعم للأدوات (مثل قواعد بيانات التجميع لدعم الإكمال التلقائي لـ Clang أو التحليل الثابت). لا يوجد دعم ويندوز. تجنب بأي ثمن.
• bazel : نظام إدارة / بناء من Google Hunter . أيضًا ، تميل برامج Google إلى التركيز على ما تحتاجه Google ، وليس الجمهور بشكل عام. جديد جدًا لقياس المسار طويل المدى.

أحاول دفع CMake كلما سنحت لي الفرصة لأنني أريد معيارًا واقعيًا لـ C ++ ولديه أكبر "حصة في السوق" في الوقت الحالي.

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

أنا لا أفهم. من المحتمل أن تكون لغة C ++ لغة بناء فظيعة. البطء له علاقة أكبر بنظام البناء الداخلي AFAIK وليس بتفاصيل لغة البرمجة النصية المستخدمة.

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

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

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

بالإضافة إلى ذلك ، فإن Scons بطيئة ليس لأنها مكتوبة بلغة Python ، ولكن لأنها تُنفذ الإنشاء أيضًا. إنه نظام بناء مباشر ، مثل make أو ninja ، ولكنه يستخدم أيضًا كميات هائلة من XML للتعريفات وكمية كبيرة من شفرته هي في الواقع مجرد تحويلات XSLT.

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

أخيرًا ، يجب أن أشير إلى أن هناك العديد من أنظمة بناء التطوير حيث ستتمكن من كتابة نصوص بلغة C ++ (أنا في الواقع أكتب أحدها). ومع ذلك ، أطلب من godot الانتقال إلى نظام بناء غير موجود بعد ( والأسوأ من ذلك ، أنني أكتب بنفسي) متعجرفًا بعض الشيء ، في رأيي غير المتواضع ؛)

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

أنا أتفق تمامًا مع reduz أنني لا أجد أن SCons بطيئة أيضًا.

كما قال @ slurps-mad-rips:

السكونز بطيئة ليس لأنها مكتوبة بلغة بيثون ، ولكن لأنها تُنفذ البناء أيضًا

رجل الشمعدانات:

تدعم scons بناء أهداف متعددة بالتوازي عبر الخيار a -j الذي يأخذ ، كحجة له ​​، عدد المهام المتزامنة التي قد يتم إنتاجها:
الشمعدانات-ي 4

لدي وحدة معالجة مركزية 8c16t ، لذا فإن استخدام "scons p = x11 -j 18" سريع جدًا بالنسبة لي.
إنها أسرع بـ 10 مرات من استخدام "scons p = x11" كإعداد افتراضي "-j 1".
هل يمتلك شخص ما وحدة معالجة مركزية أساسية واحدة في عام 2018؟
دع وحدة المعالجة المركزية الخاصة بك تعمل بشكل كامل.
يرجى محاولة إعطائها.

لا يمتلك كل شخص وحدات المعالجة المركزية الكبيرة هذه ، ولكن الأهم من ذلك ، أن الميزون (حسنًا ، النينجا) أسرع بكثير في عمليات إعادة التجميع المتزايدة. تقوم Scons ، بشكل افتراضي ، بإجراء مجموع تجزئة MD5 لمعرفة ما إذا كان الملف قد تغير. يستخدم Godot إعداد الطابع الزمني MD5 ، مما يعني أنه لن يقوم بتجزئة الملف إلا إذا تم تغيير الطابع الزمني. لا يزال الأمر سخيفًا.

أعتقد أن أفضل طريقة لإثبات الأفضل هو كتابة واحدة جديدة ومشاهدة :)

Scons ليست سريعة للعديد من الأشخاص ، خاصةً مستخدمي windows الذين يواجهون مشكلة في أي شيء أعلى من -j 1.

@ slurps-mad-rips يعتمد ذلك على المشروع. يبدو أن النينجا تضخم سرعتها أكثر من اللازم. انظر هذا المقال: http://david.rothlis.net/ninja-benchmark/. يبدو أن عد الملفات المصدر هو أفضل رهان لك هنا. إذا كان <20K لا يحدث فرقًا كبيرًا.

isaachier هذا المعيار هو بين الصنع والنينجا ، وليس النينجا والسكونز ، لذلك عليك أن تسامحني إذا لم أرغب في الاهتمام بها. ؛)

أعتقد أن أفضل طريقة لإثبات ما هو أفضل هو كتابة جديد على ومشاهدة :)

أوافق ، ليس هناك فائدة من سفك الدراجات. إذا كان لديك رأي حول نظام بناء أفضل ، فقم بتنفيذه وأثبت أنه أفضل. وإلا فهذه مناقشة للرأي ولن تؤدي إلى شيء. لقد أجرىfire بالفعل اختبارًا جزئيًا مع bazel: https://github.com/godotengine/godot/issues/18518.

@ slurps-mad-rips يا موضوع مختلف تمامًا ، وليس SCons. أنا فقط قصدت أن تصنع مقابل النينجا ليس فرقًا مجنونًا.

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

في الوقت الحالي ، يتم وضع الكثير من التعليمات البرمجية والعمليات مباشرة في سكربتات scons وهذا يجعل الانتقال إلى نظام بناء آخر أكثر صعوبة. إذا كان هناك أي شيء سأجادله ، فيجب قضاء الوقت في فصل برامج Python النصية الحالية التي تولد رمزًا من scons ، لأن هذا من شأنه أن يجعل الانتقال إلى نظام بناء آخر مثل meson أو cmake أو حتى bazel أسهل كثيرًا.

الشيء الجيد أنه تم دمج التصحيح للتو لإخراج جميع عمليات إنشاء التعليمات البرمجية. https://github.com/godotengine/godot/pull/17595 لا تستسلم!

مدير مشروع SCons هنا. بضع ملاحظات:
1 - SCons قيد التطوير النشط ومنذ انتقالنا إلى Github نشهد زيادة في معدل طلبات السحب.
2 - لقد حددنا بعض الأجزاء المحددة من SCons المسؤولة عن حوالي 50٪ من وقت البناء الإضافي الخالي ونعمل بنشاط على معالجة ذلك. (الوظيفة الفرعية)
3 - لقد بدأنا في دعم Python 3.5+ (وكذلك 2.7.x) باستخدام SCons 3.0
4 - دعني أقترح أنه بدلاً من محاولة النقل إلى أنظمة بناء مختلفة N ، فإن المساهمة ببعض الوقت للمساعدة في تحسين SCons قد يكون استخدامًا أكثر فعالية لوقت المطور
5- حددنا وعالجنا من خلال التنميط بعض الثمار المنخفضة المعلقة في تحسين الأداء والتي تم إصدارها في 3.0.0 و 3.0.1. إذا كنت تستخدم إصدارًا سابقًا ، فيمكن أن يكون الإنشاء التزايدي الفارغ أبطأ بنسبة 5-15٪. (بافتراض Python 2.7.x)

كما هو الحال دائمًا ، فإن مشروع SCons جاهز ومستعد لمساعدة المشاريع التي تستخدم SCons في المشكلات التي تواجهها.

بعض "الإحصائيات" لـ SCons & godot.

لقد استخدمت (وما زلت أفعل) Q6600 وهو معالج رباعي النواة من عام 2008 أو نحو ذلك مع 2.4 جيجا هرتز (وتعليمات أقل لكل دورة) من المعالجات التي نستخدمها "جميعًا" اليوم (i7s).

في Q6600 ، استغرق البناء ما بين 3 إلى 5 دقائق (أو أكثر ، ولكن العدد الدقيق ليس بهذه الأهمية) ، منها حوالي 35-40 ثانية تم إنفاقها بواسطة SCons لتحليل شجرة التبعيات والأشياء (العمل التحضيري) ... لذا ، فإن 80٪ من الوقت يقضي في تشغيل عملية cl.exe (مترجم MSVC) مرارًا وتكرارًا.

لذلك ، من الحكمة الأداء والتحسين ، ما لم يكن لدى SCons (python حقًا ، وليس SCons) نظام استدعاء عملية رهيبة يستغرق وقتًا أطول مما ينبغي أو بعض الأدوات الأخرى لا تجمع ملفًا واحدًا لكل عملية (مثل SCons حاليًا) و 1 تعتبر العملية لكل ملف إضافي مهمة (لست خبيرًا في الأجزاء الداخلية للتوافق cl.exe والنفقات العامة لبدء التشغيل) ، ومن المحتمل أن يكون تحسين الأداء الوحيد الذي قد ينتج عن نظام بناء أسرع هو بناء مرحلة شجرة التبعية ، وغيرها من الأعمال التمهيدية للتعقيد .

لذلك ، نحن نقوم بتحسين تلك 35-40 ثانية من بناء 5 دقائق (على i7 الآن ربما نقوم بتحسين 20 ثانية من الإعداد الأساسي الفردي من بناء متعدد النواة مدته 3 دقائق).

لذا ، للتلخيص ، إذا كنت أتذكر بشكل صحيح ، فإن 3 إلى 5 دقائق هي في الواقع بناء متعدد النواة

لذا ، فإن "تحسين" SCons بعيدًا يعني أن تحسين تلك الثواني الـ 35 الأولى من الإنشاءات يبدأ بشكل أو بآخر ...

هذا بقدر ما يتعلق الأمر بـ "التحسينات" عندما يتعلق الأمر بـ SCons مقابل نظام بناء أسرع آخر ... من الممكن أن يتم تحسين التجميع الفعلي قليلاً عن طريق تجنب استدعاء cl.exe واحد لكل ملف obj ، ولكن هذا فقط إذا إن النفقات العامة للعملية كبيرة (أخشى أن يكون محرك الأقراص الثابتة دائمًا هو عنق الزجاجة الفعلي للإدخال والإخراج (وليس وحدة المعالجة المركزية) ، وهو أمر لا يمكن تجنبه / تخفيفه بدون SSD)

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

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

كانت فكرتي الخارقة منذ عامين هي محاولة إرفاق "مراقب" نظام ملفات بـ SCons ، وتشغيل SCons وإعادة تجميع ملف واحد تم تغييره (وتبعياته ، هذا تلقائي) ، ثم اجعله يربط كل شيء مرة أخرى ... على الرغم من أنني أدرك اليوم أن الارتباط لا يزال من المحتمل أن يؤدي إلى عملية اكتساح كاملة للتبعية ... ومع ذلك ، يمكن القضاء على عملية مسح / إعادة بناء شجرة التبعية مع خيار ثم تستخدم SCons شجرة dep المخزنة مؤقتًا ... والتي توفر حوالي 15-20 ثوانٍ من خطوة 35 ثانية للحساب المسبق (يبدو أن أول 15 ثانية لا مفر منها) على الرغم من أن هذا قد لا يضمن بنية "مثالية" دائمًا كما تفعل SCons (على الرغم من أن ذلك قد لا يكون مهمًا لعمليات الإنشاء الإضافية في التطوير ... إذا قررت أن السرعة هي مقايضة جديرة).

لدي الآن معرفة كافية بإمكانية اختراقها من خلال ساعة npm و npm ... أو أي نظام آخر لست على دراية به حاليًا ... ولكن هذا لوقت لاحق ، وعندما يكون لدي وقت (ليس حاليًا).

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

إذا كنت ترغب في تكرار / إعادة الإحصائيات الخاصة بي ، فما عليك سوى تصفح مستندات SCons حتى تقوم بتشغيل المعلومات الإحصائية (عناصر المؤقت) و / أو إيجاد طريقة لإيقاف إعادة تحديد التبعية (تلك الثواني الـ 20 إلى 30-35 الأولى من "الحساب المسبق" ) ...

أو للحصول على حل يدوي أقل قليلاً ، يجب أن تكون معلومات تصحيح أخطاء المؤقت موجودة بالفعل (تحرير: ربما لا ، شخص ما فعل ما يشبه تحديثًا رائعًا لجيل مشروع مقابل ، قد تكون هذه الفقرة معلومات قديمة) في مشروع VS الآلي الذي تم إنشاؤه بواسطة SCons (في نهاية ملف SConstruct) ... يمكنك العثور على معلومات حول كيفية إنشاء مشروع VS في "البرنامج التعليمي لتجميع Windows" على موقع godot الإلكتروني. يمكنك بعد ذلك تشغيل SCons من VS ، وأعتقد أن المشروع الذي تم إنشاؤه لا يزال من المحتمل أن يعمل ، على الرغم من أنني لم أختبره في Godot 3 ... إنه خيار ، ولكن إنشاء scons إلى> log.txt هو أيضًا خيار آخر (إلخ) ...

نأمل أن يكون شخص ما قد وجد هذه المعلومات مفيدة.

Griefchief فقط

في الواقع ، "البناء الإضافي الفارغ" (لا يوجد شيء يحتاج في الواقع إلى إعادة بنائه ، ولكن ستظل scons بحاجة إلى معالجة شجرة التبعية بأكملها لضمان ذلك) هي الحالة التي نعمل عليها.

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

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

في ملاحظة جانبية ، يمكنك تجربة MSVC_BATCH لمعرفة ما إذا كان ذلك يؤدي إلى تسريع بناء النوافذ:

MSVC_BATCH
عند التعيين إلى أي قيمة صحيحة ، تحدد أن SCons يجب أن تقوم بترجمة ملفات الكائنات دفعة واحدة عند استدعاء برنامج التحويل البرمجي Microsoft Visual C / C ++. سيتم إنشاء جميع مجموعات الملفات المصدر من نفس الدليل المصدر والتي تنشئ الملفات المستهدفة في دليل الإخراج نفسه والتي تم تكوينها في SCons باستخدام نفس بيئة البناء في استدعاء واحد للمجمع. سيتم فقط تمرير ملفات المصدر التي تم تغييرها منذ إنشاء ملفات الكائنات الخاصة بها إلى كل استدعاء للمترجم (عبر متغير الإنشاء $ CHANGED_SOURCES). سيتم تجميع أي تجميعات لا يتطابق فيها اسم ملف الكائن (الهدف) الأساسي (مطروحًا منه obj.) مع الاسم الأساسي للملف المصدر بشكل منفصل.

@ bojidar-bg نعم ، نعم ، كنت أتحدث بالفعل عن الإنشاءات الإضافية أيضًا ، شكرًا لك على النصيحة: D

bdbaddog مرحبًا

ولم أكن أرغب في إرسال اختبار الاتصال إليك لأنني لم أرغب في "إهدار" وقتك: D ، ولكن أعتقد أنني سأفعل ذلك إذا أمضيت بعض الوقت في إنشاء / scons في godot في المستقبل (أخطط لذلك ، أنا مشغول جدا))

شكرا لمساهمتك هنا!

bdbaddog BD ، نظرًا لأنك تقدم الدعم ، إذا

إذا قمت بإرفاق ساعة npm بنظام الملفات (مصدر godot) وعرفت الملف الدقيق الذي تم تغييره ، فهل يجلب لي ذلك أي فوائد مع SCons؟

الآن يمكنني تشغيل scons من خلال ساعة npm ودفع الملف إليها ...

scons [خيارات godot] the / file / that / was / تغيرت.

من الواضح أن هذا سيعيد تجميع هذا الملف ، وربما يتجنب شجرة جودو الكاملة؟ صيح؟ لذا لن يستغرق اجتياز الشجرة الآن 20 ثانية ، ولكن أقل من احتمال واحد ، لكني أحصل على ملف .obj محدث (أو أكثر ، يعتمد على ما تغيره). لن يمر فعليًا عبر شجرة مستودع godot بأكملها لهذا الملف الواحد؟ لدي ميزة في اجتياز الشجرة بشكل أقل في هذا المثال (وربما مزايا أخرى في مرحلة ما قبل الحوسبة التي لا يمكن اكتسابها من خلال إعادة استخدام ذاكرة التخزين المؤقت لشجرة التخزين ، مثل عدد أقل من الملفات بشكل عام لتصفحها؟)؟

الآن ، إذا كانت لدي ميزة ، وإذا أردت فقط ربط كل شيء مرة أخرى ، فهل سأحتاج إلى اجتياز شجرة كاملة لمرحلة ربط "بسيطة"؟

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

هل هناك شيء في فكرتي لن يعمل كتحسين (عمليًا ونظريًا) ، وهل لديك اقتراحات أخرى (لا يجب أن تضمن تصميمًا مثاليًا إذا كان هناك شيء مثل npm watch يمكنه الاهتمام بالأشياء ، فلا بأس أيضًا )؟ هل يمكنك أن تنصح من فضلك؟ شكرا لك!

للتلخيص ، حالة الاستخدام مشابهة لما يلي:

1) قم بتشغيل filewatcher مثل npm watch على دليل مصدر godot
2) يقوم المستخدم بحفظ / تعديل ملف قديم
3) يتم تشغيل scons على الفور لهذا الملف بواسطة npm.
4) إذا كان التجميع ناجحًا ، فإن npm يوجه scons لتشغيل الرابط وربط الملف القابل للتنفيذ.

4.1) إذا تم صرف شجرة Dep (تم تشغيل بنية كاملة بالفعل) ، فيمكن لـ npm توجيه الرابط للربط فقط في هذه المرحلة بإصدار مخبأ من شجرة dep
4.1) إذا لم يتم الكشف عن شجرة التخزين المؤقت ، فإن الساعة npm تشغل بناء godot كامل
4.2) إذا تم اكتشاف إبطال ذاكرة التخزين المؤقت ، مثل إضافة ملف جديد ، فقم بإجراء مسح كامل للشجرة (لن تستخدم npm خيار "استخدام شجرة التخزين المؤقت" مع scons).

آمل أن يجعل هذا فكرتي أسهل قليلاً في الفهم ، واسمحوا لي أن أعرف ما هو الخطأ فيها في هذه المرحلة ؛ د

ملاحظة: أعتقد أن هذا هو الأمر الذي يحلق لمدة 15 ثانية من البناء التزايدي الفارغ البالغ 35 ثانية ، مع عواقبه "الواضحة" ... أريد أساسًا أتمتة ما هو موصوف هنا (أكثر أو أقل ، + دع السكونز تعرف الملف الدقيق تم تعديله إذا كان ذلك يساعده بأي طريقة (أو يمكن أن يساعده)):

https://www.scons.org/doc/latest/HTML/scons-user/ch06s04.html

إذن بعض الأشياء هنا (بدون ترتيب معين ، لكني أستخدم الأرقام لأن yolo

1) البنيات الفارغة التزايدية هي في الأساس لا شيء تحت أي أداة تولد ملفات النينجا. يحتوي Chrome ، AFAIK ، على بنية تراكمية فارغة أقل من ثانيتين. هذه ملاحظة مهمة ، حيث إن الانخفاض لمدة 35 ثانية إلى 15 أقل من npm watch لا يزال كبيرًا جدًا مقارنة ببنية Ninja على أساس الميزون أو cmake. يقوم Ninja أيضًا بنفس الشيء الذي يقوم به Scons لأنه يقوم بإعادة بناء في حالة تغيير سطر الأوامر (إجراء ، بالطبع ، لا يقوم بذلك)

2) نفذت CMake مؤخرًا القدرة على استخدام CONFIGURE_DEPENDS كوسيطة لنظام glob. لقد تمت التوصية بهذا الأمر دائمًا لأنه لم يتم دعم اكتشاف تغيير الدليل من قبل أدوات مثل xcodebuild و msbuild تاريخياً (وحالياً). هذا شيء واحد يمكن لشركة Scons تحسينه ، لكن ليس لدي الوقت ولا الصبر للتعمق في المشروع لتنفيذ ذلك. بشكل أساسي ، يقوم كل نظام تشغيل بتحديث دليل عندما تتغير محتوياته ، سواء كان ملفًا مضافًا أو ملفًا معدلًا أو ملفًا تمت إزالته. عند إجراء تغييرات تدريجية ، يمكن للمرء أن يتحقق ببساطة من الدلائل التي تغيرت وتعرف فقط على تلك الموجودة في فحص إعادة التكوين. يمكن أن يقلل هذا من العمل المنجز لأنك لا تلمس الشجرة بأكملها ، ولكن أجزاء أصغر. بالنسبة للمشاريع الصغيرة هذا جيد. ما إذا كان هذا سيفيد godot أم لا سيتطلب بعض الاختبارات وهذا كثير من العمل للتحقق مما إذا كان سيساعد.

3) في حين أنه من الجيد أن نرى أن Scons تحظى باهتمام أكبر ، فأنا شخصياً أعتقد أنه من الأفضل للمجتمع ككل أن ينتقل godot إلى نظام بناء أكثر استخدامًا. لا أستطيع التفكير خارج godot في أي مشروع كبير يستخدم Scons. انتقل GNOME / GTK مؤخرًا إلى ميزون (تخطي CMake) ، وكان KDE يعمل على CMake لبعض الوقت. على الرغم من أنه دليل قصصي (وبالتالي تحيز تأكيد أساسي) ، فأنا أعرف العديد من مطوري C ++ الذين يرغبون في تجربة godot لكنهم لا يفضلون لمس السكونز مرة أخرى. إن إزالة التجارب السيئة وبالتالي الطعم الحامض المتبقي في أفواه المطورين أمر صعب ، وأتمنى بصدق أن يكون مشروع Scons هو الأفضل. لكنني أعلم أن مجتمع C ++ بشكل عام يكره بالفعل وقت الترجمة الطويل. تعد الإنشاءات الفارغة المتزايدة الطويلة (أو حتى الإنشاءات المتزايدة الطويلة لملف واحد) كابوسًا في العالم الحديث.

أعتزم المحاولة مرة أخرى ، لكنني قد أستهدف CMake من أجل ذلك. يعد الانتقال من CMake إلى meson أسهل كثيرًا بفضل امتلاك ميزون لبرنامج نصي للتحويل يمكنه القيام بالكثير من العمل. قد يجعل CMake التعامل مع التبعيات أسهل قليلاً مع وحدة FetchContent الجديدة. سنرى كيف يعمل. سأقول ، أنا سعيد لأن هذه البرامج النصية تم نقلها إلى ملفات منفصلة. سيكون استخدام CMake أمرًا رائعًا فقط إذا كان الانتقال إلى معيار C ++ مختلف بسيط مثل target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>)

من الواضح أن أي أشياء متعلقة بنظام البناء ستكون مثيرة للجدل ، لكن المحاولة لن تؤذي.

لأكون صادقًا تمامًا ، (وقد يكون هذا قاسًا) ليس لدي رغبة في الغوص بعمق في مشروع Scons لتحسينه. ربما بعد عام 2020 عندما مات Python 2.7 رسميًا أخيرًا ويمكن للمشروع المضي قدمًا إلى Python 3.5+ فقط سيكون الأمر يستحق التحقيق أو التحسين ، ربما باستخدام عمليات غير متزامنة. لكن حتى ذلك الحين ، لا أفضل أن ألمسها.

ربما بعد عام 2020 عندما مات Python 2.7 رسميًا أخيرًا ويمكن للمشروع المضي قدمًا إلى Python 3.5+ فقط الأمر الذي يستحق التحقيق أو التحسين

يدعم Scons 3 Python 3.5+: https://scons.org/tag/releases.html .

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

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

حيث يصعب تحديد إعدادات التصميم الخاصة بك إذا كنت مستخدمًا ،

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

Faless لا أحد ينكر أن لغة CMake فظيعة. لكن التنفيذ هو الأفضل في فئته. لقد كنت أفكر في إمكانية كتابة مترجم من لغة أفضل للتخفيف من حدة المشكلة.

@ OvermindDL1 أحب اقتراح قراءة CGold.

إذا تم طلب ذلك ، فسيتم استخدام CMake بشكل خاطئ

حسنًا ، أعتقد أن جميع البرامج التي واجهتها كانت خاطئة حينها.

لأكون صادقًا ، أكره الاضطرار إلى تغيير العلامات عبر -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (حقًا؟ on ؟). ناهيك عن فكرة تحرير ملف التخزين المؤقت O_o. أو إذا كنت أرغب في تغيير علامة ، فسينتهي بي الأمر بشكل أساسي إلى حذف مجلد الإنشاء والبدء من نقطة الصفر (لأن ذاكرة التخزين المؤقت تختلف ، كما تعلمون!) ... كثيرًا بالنسبة للبنيات المتزايدة ...

تحرير: أيضًا ، أحد الأشياء التي أحببتها حقًا في Scons (في Godot على الأقل ، وقد يكون هذا ممكنًا مع نظام إنشاء آخر بالطبع) ، هو أنني لم أقرأ في الواقع أي معيار أو مستند ، لقد قمت بتشغيل scons -h في مجلد Godot

95٪ من ملفات البناء التي رأيتها على GitHub خاطئة. يتكاسل الناس بشأن بناء الأنظمة ويتبعون ممارسات عبادة الشحن لتجميع شيء ما معًا.

isaachier ، فقط كمقياس ، هل يمكنك تقديم مثالين لملف CMake سيئ وجيد؟ كيف تفكر في هذا: https://github.com/ARMmbed/mbedtls/blob/development/CMakeLists.txt ؟

أفضل مما رأيته. ومع ذلك ، إذا كنت لا تستخدم CMake> = 3.0 ، فإن تجربتك مع CMake ليست حديثة.

حسنًا ، أعتقد أن جميع البرامج التي واجهتها كانت خاطئة حينها.

أنا أميل إلى رؤية ذلك بشكل جيد في الوقت الحاضر.

لأكون صادقًا ، أكره الاضطرار إلى تغيير العلامات عبر -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG = on (حقًا؟ على؟). ناهيك عن فكرة تحرير ملف التخزين المؤقت O_o. أو إذا كنت أرغب في تغيير علامة ، فسينتهي بي الأمر بشكل أساسي إلى حذف مجلد الإنشاء والبدء من نقطة الصفر (لأن ذاكرة التخزين المؤقت تختلف ، كما تعلمون!) ... كثيرًا بالنسبة للبنيات المتزايدة ...

ليس عليك استخدام on ، يمكنك استخدام true ، 1 ، ومجموعة متنوعة من الأشياء الأخرى. هو جعله بحيث يمكنك اختيار اسم منطقي مناسب يتدفق جيدًا مع اسم العلم.

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

ومع ذلك ، يجب على كل شخص لمس أنظمة إنشاء C / C ++ قراءة CGold بالإضافة إلى الدليل الرسمي لـ CMake. هو حقا سهلة الاستخدام CMake الحق، غالبا ما يكون قدرا كبيرا أقصر أيضا. لا ينبغي استخدام منهجيات CMake2 القديمة. على الرغم من ذلك ، فإن أي شخص يعتمد على إصدار CMake 2.x يفعل أشياء خاطئة تمامًا (لا يستخدم الأهداف وسلاسل الأدوات بشكل صحيح ، ولا يحدد الخيارات بشكل صحيح ، إلخ ... إلخ ...).

شكرًا على التفسيرات ، بينما ما زلت متشككًا ، أتطلع إلى رؤية كيف سيعمل مع Godot :).

@ slurps-mad-rips مشاركتك التي تحتوي على كود مثال CMake المفترض لتمكين وضع C ++ 11 هي CMake غير قياسية تمامًا لمجموعة متنوعة من الأسباب ، بما في ذلك على سبيل المثال لا الحصر:

• تحديد المتغيرات غير المكشوفة.
• تم تعيين وسيطات Toolchain في ملف غير toolchain.
• بالتأكيد ليس كيف تفعل شيئًا مثل تمكين وضع C ++ 11.
• غير فعال.

بالنظر إلى كود الميزون الموصوف ذاتيًا على أنه مبسط في هذا المنشور:

cxx = meson.get_compiler('cpp')
# This is an extremely simplified approach. One can do a different option when dealing with MSVC and gcc support.
args = compiler.get_supported_arguments('-std=c++11', '-stdlib=libc++')
add_project_arguments(args)

المعادل المبسط (حيث يمكنك إضافة المزيد من الخصائص أيضًا) سيكون CMake:

set_target_properties(godot PROPERTIES CXX_STANDARD 11)

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

بالنظر إلى وجود ملف CMake Toolchain الذي تم إنشاؤه مسبقًا لأي سلسلة أدوات يمكنك التفكير فيها (بما في ذلك جميع معايير MSVC من مختلف الأصناف ، GCC / Clang ، android ، iOS ، emscripten ، إلخ ... إلخ). لا ينبغي إعادة اختراع العجلة. إذا كان المستخدم الذي يقوم بتجميع شيء مثل godot يريد استخدام برنامج التحويل البرمجي المخصص الخاص به مع وسيطات سطر أوامر فريدة (مثل أخذ مترجم Intel أو ربما إلى شريحة مخصصة أو مجرد RPi بسيط) ، فلن يحتاج نص الإنشاء إلى الاهتمام به أو بحاجة إلى أي تغييرات على الإطلاق (قد يكون الرمز بالطبع ، ولكن على النحو الأمثل لا ينبغي أن يحدث أبدًا لأن CMake يمكنه إخباره بكل ما يتم دعمه عبر التعريفات) ويمكن للمستخدم توفير ملف سلسلة الأدوات المخصص الخاص به لاستخدامه.

تحرير: ولا تستبعد أبدًا الدعم الواسع النطاق. لا يمكنني العثور على أي شيء حول قدرة meson على إنشاء ملفات مشروع لـ KDevelop (IDE الذي أستخدمه ، والذي يستخدم بشكل مثير للاهتمام CMake لأنه تنسيق بناء ، وأحيانًا أستخدم CLion في العمل ، كما أنه يستخدم CMake) ، حيث يخرج كل IDE تقريبًا ( حتى Visual Studio!) يمكنه فتح مشاريع CMake أصلاً الآن (بالإضافة إلى أن CMake قادرة على إنشاء مشاريع لمعظم IDE مباشرة إذا كنت ترغب في ذلك).

تضمين التغريدة

إنه ليس CMake غير قياسي على الإطلاق. يستهدف نموذج التعليمات البرمجية CMake 3.0 ، وهو إصدار لا يوجد فيه CXX_STANDARD . يمكنك بسهولة أن ترى من هنا أنك تستخدم target_compile_features مع cxx_std_ ورقم المعيار. هذه هي طريقة cmake الجديدة والحديثة لتعيين الإصدار القياسي. set_target_properties هو نهج أقدم لكل هدف.
في الواقع ، الشفرة الدقيقة المأخوذة من وثائق CMake هي

target_compile_features(mylib PUBLIC cxx_std_11)

ومع ذلك، CXX_STANDARD لا يحدد LIBC ++ دعم رنة من الاستخدامات رنة libstdc ++ بشكل افتراضي على لينكس ما لم يتم تكوين (وانها لم تهيئتها لاستخدام LIBC ++ بشكل افتراضي على معظم توزيعات لينكس، وهذا من شأنه أن يسبب أخطاء رابط والقضايا ABI) . الطريقة الوحيدة للقيام بذلك في هذا الوقت هي التحقق مما إذا كان المترجم يدعم -stdlib=libc++ وتمريره إلى المترجم عبر تعبير المولد. لا يوجد شيء ينطوي على متغيرات غير مكشوفة بخصوص هذا.

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

يعد CMake 3.0 قديمًا بدرجة كافية بحيث لا يتم دعمه (10 يونيو 2014). لا ينبغي لأي شخص تشغيل أي شيء أقل من CMake 3.10 حاليًا ، على الرغم من أن البقاء على اطلاع دائم مع CMake 3.12 هو المفضل في الوقت الحالي.

ونعم ، المثال الذي قدمته موصى به تمامًا ضد (أعتقد أنه حتى CGold يذكر عدم القيام بذلك).

ونعم ، أعني target_compile_features. ^. ^ ؛

ومع ذلك ، لا يقوم CXX_STANDARD بتعيين دعم libc ++ لـ clang حيث يستخدم clang libstdc ++ افتراضيًا على نظام Linux ما لم يتم تكوينه (ولم يتم تكوينه مطلقًا لاستخدام libc ++ افتراضيًا في معظم توزيعات Linux ، حيث قد يتسبب ذلك في حدوث أخطاء في الرابط ومشكلات في ABI). الطريقة الوحيدة للقيام بذلك في هذا الوقت هي التحقق مما إذا كان المترجم يدعم -stdlib = libc ++ وتمريره إلى المترجم عبر تعبير المولد. لا يوجد شيء ينطوي على متغيرات غير مكشوفة بخصوص هذا.

جميع سلاسل الأدوات الحالية تفعل ذلك من أجل clang على ما يرام ، على الأقل مع C ++ 14 لأن هذا هو ما أجمعه (وزوجان من C ++ 17).

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

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

الطريقة الوحيدة للقيام بذلك في هذا الوقت هي التحقق مما إذا كان المترجم يدعم -stdlib = libc ++ وتمريره إلى المترجم عبر تعبير المولد.

ومع ذلك ، نعم ، هذه هي وظيفة ملف toolchain ، الذي يجب ألا يظهر مطلقًا في ملف الإنشاء على الإطلاق .

لا يوجد شيء ينطوي على متغيرات غير مكشوفة بخصوص هذا.

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

يعد CMake 3.0 قديمًا بدرجة كافية بحيث لا يتم دعمه (10 يونيو 2014). لا ينبغي لأي شخص تشغيل أي شيء أقل من CMake 3.10 حاليًا ، على الرغم من أن البقاء على اطلاع دائم مع CMake 3.12 هو المفضل في الوقت الحالي.

لا ينبغي أن يفعلوا ذلك ، ومع ذلك فإن بعض الأماكن كذلك. بالنسبة لمحرك اللعبة الذي يحاول البقاء على اطلاع بأحدث التقنيات ، فإن البقاء على أحدث إصدار من CMake أمر جيد. ومع ذلك ، فأنا على دراية كاملة بالمشاريع النشطة للغاية العالقة في الإصدارات القديمة مثل 3.5 وفي بعض الحالات 3.4. في الواقع ، لا تزال بعض مكتبات C المعروفة تستهدف CMake 2.8 (انظر: SDL2 ، libssh2 ، libgit2 ، إلخ.) إنه ألم كبير في المؤخرة بالتأكيد.

ومع ذلك ، نعم ، هذه هي وظيفة ملف toolchain ، والتي يجب ألا تظهر مطلقًا في ملف الإنشاء على الإطلاق.

إن القيام بهذا الافتراض (أن ملفات toolchain مكتوبة جيدًا وتغطي جميع الأنظمة الممكنة وجميع إصدارات CMake) يتطلب مشاكل في النظام البيئي C ++ العام الحالي. عند استخدام clang ، يجب أن توفر المكتبة خيار التجميع لـ libstdc ++ أو libc ++ (خاصة عند استخدامه عبر مكالمة FetchContent ). CheckIncludeCXX و CheckCXXCompileFlag ضرورية حتى لبعض الأعلام التي لا توجد ضمن دول مجلس التعاون الخليجي ولكنها موجودة ضمن Clang (والعكس صحيح). المشكلة الأساسية هنا هي أن واجهات المترجم قد تباعدت بمقدار كبير وبدلاً من أن يقضي البائعون الوقت لتسهيل خيارات التوافق أو حتى مناقشة واجهة مشتركة ، فإن هذا السلوك يدفع إلينا ، نحن المطور عندما يكون كل ما نريد فعله هو كتابة التعليمات البرمجية. صدقني ، لا أحد على هذا الكوكب أكثر انزعاجًا من حالة أنظمة بناء C و C ++ وإدارة التبعية مني ، ولكن هناك حاجة إلى البراغماتية للمكتبات الموجودة على CMake. الشيء الجميل في الانتقال من نظام البناء إلى CMake هو أنه يمكننا بدء تشغيل البوابة بأحدث الميزات وأفضلها. تصبح المشكلة ركودًا في نظام البناء لأن لا أحد يريد لمسها (باستثناء تلك الروح الشجاعة التي دفعت إنشاء نصوص إنشاء الكود إلى نصوص منفصلة) ، ولكن ستكون هناك حاجة إلى بعض العمل للتأكد من عدم خروجها عن السيطرة (وهو ما سيحدث لأن ... أعني أنه نظام بناء. إنهم يفعلون ذلك دائمًا)

يجب أن أكون الشخص الوحيد الذي يستمتع بالفعل بكتابة نصوص البناء وخاصة في CMake ؛).

إن القيام بهذا الافتراض (أن ملفات toolchain مكتوبة جيدًا وتغطي جميع الأنظمة الممكنة وجميع إصدارات CMake) يتطلب مشاكل في النظام البيئي C ++ العام الحالي. عند استخدام clang ، يجب أن توفر المكتبة خيار التجميع لـ libstdc ++ أو libc ++ (خاصة عند استخدامه عبر مكالمة FetchContent).

يجب أن تكون مثل هذه الأشياء عبارة عن خصائص يتم تمريرها إلى سلسلة الأدوات التي يمكن لسلسلة الأدوات العمل عليها.

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

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

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

يجب أن أكون الشخص الوحيد الذي يستمتع بالفعل بكتابة نصوص البناء وخاصة في CMake ؛).

أنا أستمتع بها مقارنة بالبدائل بالتأكيد ، على الرغم من أنني كتبت فيها لفترة كافية تجعلها منطقية بالنسبة لي ، على الرغم من أن هذا بالتأكيد لا يعني أنه سيكون للجميع. ^. ^ ؛

لقد استخدمت الكثير من أنظمة البناء المختلفة على مر السنين. الشيء الأكثر منطقية بالنسبة لي مؤخرًا هو CMake ، لكن يمكنني بالتأكيد رؤية جاذبية SCons ومدى مرونتها.

حتى لو لم يكن SCons مثاليًا (ما هو نظام البناء؟) فقد يكون جيدًا بما فيه الكفاية.

• هل يوفر الميزات المطلوبة؟
• ما مقدار النفقات العامة التي تخلقها؟

إذا أحرزت SCons نقاط "جيدة بما يكفي" لكلا النقطتين ، فاحتفظ بها.

هل أي منكم يقترح استبدال SCons بشيء آخر قد بذل جهدًا فعليًا لمعرفة كيفية عمل نظام بناء Godot؟

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

كل الجهود التي بذلها أولئك الذين قالوا "سأقوم ببناء نظام Godot لبعض الأشياء الأخرى" فشلت فشلاً ذريعًا حتى الآن عند إدراك مدى تعقيد ما تهتم به SCons.

بالنسبة لي ، إنها أفضل أداة للوظيفة حتى الآن. لا شيء قريب منه. إذا اشتكيت يا رفاق من وقت التجميع الأساسي (وهو 4/5 ثوانٍ فقط على نظام متوسط ​​إلى مرتفع مع SSD) ، فعليك حقًا أولاً محاولة فهم كل شيء يفعله Godot عند البناء ومعرفة كيفية أدائه في CMake أو أي شيء آخر .

لقد ألقيت نظرة. أنا لست مقتنعًا أنه لا يمكن التراجع عنه في CMake أو في أي مكان آخر. لكنني كسول أيضًا ؛). سوف نرى ماذا سيحدث.

كشخص قام بعمل الميناء. تمكنت من الوصول إلى النقطة التي بدأ فيها محرر Godot بدون أيقونات.

أنا متأكد من أن CMake يمكنه الوصول إلى هذه النقطة.

ملاحظة. أقرب مشروع منافس بكميات كبيرة من المنصات هو Urho3d.

لقد قمت بإعادة إنتاج نتيجة bazel الخاصة بي على cmake.

https://github.com/fire/godot/tree/cmake

افترض أن الاستوديو المرئي 2017 مثبت.

git clone https://github.com/fire/godot.git -b cmake
scons p=windows
Modify platform/register_platform_apis.gen.cpp
#include "register_platform_apis.h"

void register_platform_apis() {
}

void unregister_platform_apis() {
}

تثبيت cmake

choco install cmake ninja -y
# Open visual studio command prompt amd 64 2017 native
# Go to godot source directory
cd ..
mkdir build
cd build
cmake ../godot -GNinja
ninja

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

ملحوظة

• تعمل الرموز اعتبارًا من 71175b45f819e7cc5e4368dbf3e42abdd19af542
• عمل البرنامج النصي المرئي و GDscript

fire شكرا لهذا. أرى الكثير من الأماكن للتحسين التي من شأنها أن تجعل صيانة ملفات CMake أسهل (والوقت الذي يقضيه في إضافة ميزات جديدة أو علامات المترجم). قد أتعامل مع نهاية هذا الأسبوع المقبل ولكن الجدول الزمني معلق.

عمل رائعfire. يسعدني أن أرى شخصًا ما هنا يمكنه إنتاج شيء ما في أكثر من نظام بناء واحد: ابتسامة:.

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

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

@ slurps-mad-rips يعد تخليص ذلك من نظام SCons فكرة جيدة حتى في SCons. يمكنك تعليق GIL من خلال وجود الكثير من المنطق في العملية وإلحاق الضرر بأداء البناء. في بعض الأحيان ، يؤدي ذلك إلى بعض شروط إغلاق / فتح الملف عند البناء بالتوازي (على الرغم من حلها غالبًا عن طريق فتح الملف في سياق).

اهلا جميعا،

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

أنا أستطرد. سأضطر إلى أخذ استراحة من منفذ CMake للأسبوع المقبل أثناء حضور مؤتمر ، ومع ذلك يمكنك رؤية جهود محاولتي الأولية للتنقل هنا . يرجى أن تضع في اعتبارك أنني سأقوم بالتصوير للبقاء 1: 1 مع الفرع الرئيسي الحالي ، وعلى هذا النحو سأفرض دفع التغييرات فور دخولها حتى أتمكن من الاحتفاظ بإعادة التأسيس. عندما أقترب من الاستقرار ، سأقدم طلب سحب لتسهيل التعامل مع عمليات إعادة التأسيس ، وكذلك لتسهيل التعليق على التغييرات أو طرح الأسئلة. أعتقد أن هذا المنفذ لـ CMake ليس قابلاً للتنفيذ فحسب ، ولكنه على الأقل سيجعل شخصًا آخر (أنا) على دراية جيدة بكيفية بناء وبناء Godot بالفعل وقد أكون قادرًا على صياغة ذلك في كلمات حتى يتمكن الآخرون من الحصول عليه نظرة عامة على نظام البناء. قد يجعل هذا المنفذ أيضًا سير عمل الجميع أسهل على المدى الطويل ، خاصةً مع الإصدارات. لن أكذب ، فامتلاك ملفات CONFIGURE_DEPENDS مختلطة مع Ninja هو في الواقع لطيف للغاية.

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

هل كنت قادرًا على التحديث إلى الإصدار 3.1 ألفا الأحدث؟ يمكن أن يكون ألفا هدفًا جيدًا. تحاول حاليا البناء.

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

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

fire لقد كنت مشغولاً بالعمل في الأسابيع القليلة الماضية ، لدي موعد نهائي كبير ليوم الجمعة ، وبعد ذلك قد يكون لدي بعض الوقت و CppCon في الأسبوع الأخير من الشهر ، أنا

نعم ، كان Meson هو الهدف الأصلي للمناقشة ، لكنني أعتقد أنه من الطبيعي نوعًا ما أن يتم طرح أنظمة إنشاء أخرى ومناقشتها منذ ذلك الحين ، وربما يكون من المنطقي إبقاء المناقشة داخل هذه المشكلة هنا بدلاً من نشرها ، مثل slurps قال -ماد-مزقت.

أوافق على الانتقال إلى CMake. لديها الكثير من الدعم مع سلاسل الأدوات الخاصة بها. أصبحت إصدارات Android على سبيل المثال سهلة للغاية مقارنة بما يفعله Godot في ملف SCsub الذي يبدو أنه `` لا يمكن الحفاظ عليه '' بالنسبة لي.

كمشروع مفتوح المصدر ، يجب أن يتعامل Godot مع الحلول التي يسهل صيانتها والتي من المرجح أن يعرفها المساهمون ويكونون قادرين على المساهمة فيها.

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

يجب أيضًا أن تكون الوحدات النمطية العادية قادرة على تجميعها كمكتبات مشتركة. يرتبط هذا بـ # 19486 بحيث يمكن فصل المحرك إلى عدة مكونات قابلة للتنزيل.

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

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

أخيرًا ، أقوم بإضافة دعم لبعض أدوات البناء الإضافية للمطورين الأساسيين إذا كانوا موجودين على النظام. أشياء مثل clang-format ، أو clang-tidy ، أو ccache أو sccache ، و distcc ، و clang-check ، و address sanitizer ، و ubsanitizer ، و thread sanitizer ، إلخ. لقد تم الكشف عنها) ولكنها ستكون اختيارية للتمكين. على أقل تقدير ، سيعطي استخدام sccache أو ccache بعض التحسينات في البنية عند التبديل بين البنيات والعكس صحيح. سيكون انتظار إصدار CMake 3.13 أمرًا رائعًا لأن هذا من شأنه أن يحل بعض المشاكل التي كان علي الاعتماد عليها ، ولكن الشيء المهم هو أنني أقوم بإعداده بحيث يكون سير العمل الحالي "البدء" هو لتستمر في تشغيل pip install عبر Python 3.5 أو ما بعده ، ومع ذلك سيكون داخل Virtualenv حتى لا يضطر الأشخاص إلى العبث ببيئة نظامهم. (سيسمح هذا أيضًا للآخرين بتجربة استخدام مكتبات بيثون إضافية كاعتماديات للعديد من البرامج النصية لتوليد الكود وليس عليك تذكر إلغاء تثبيتها لاحقًا)

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

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

يمكنك أيضًا استخدام Hunter وإنشاء مستودع كود خاص بـ godot (مستودع git خاص ، مثل github على سبيل المثال) والوصول إلى جميع التبعيات بهذه الطريقة أثناء تعامله مع المبنى والتخزين المؤقت وما إلى ذلك ... حسب الضرورة وبشكل صحيح (أو قم بإرسال جميع التبعيات إلى الريبو "الرئيسي" لحزمة Hunter واستخدمها مباشرة). Hunter هو مجرد ملف cmake واحد (HunterGate.cmake) ودعوة إليه للحصول على معلومات مستودع الحزمة (سواء كانت رسمية أو مخصصة).

طلب متواضع: لقد أصبح موضوع تعليق هذه المشكلة ضخمًا - فهل سيتمكن الشخص الذي يتابعها من تلخيص المناقشة العامة حتى الآن في تعليق (وربما يمكن ربطه من RiverMesa )؟

مرحبا بالجميع. أخطط لاستخدام Godot كمحرك تالي لصنع لعبة صغيرة.

لقد رأيت هذه المحادثة وكشخص لديه خبرة في كل من CMake و Meson (وأدوات آلية ، tup ، عادي ، waf ، SCons ، تجربة مشاريع كاملة في كل هذه الأدوات ...) أردت تقديم ملاحظاتي.

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

إيجابيات cmake

• مولدات المشروع الناضجة إذا كنت تهتم بـ Visual Studio (أعتقد أن Meson يدعمه جيدًا في الوقت الحاضر ولكن لم يحاول مؤخرًا) وخاصة XCode (من المؤكد أنه غير موجود هنا).
• اعتماد أوسع ، مزيد من الدعم في IDEs
• اعتماد أوسع -> أسهل في الحصول على مساهمات (على الرغم من أن Meson هو نسيم للتعلم يجب أن أقول)

إيجابيات ميزون

• العديد من الأهداف المفيدة بشكل افتراضي: المطهرات ، الوحدة تبني مجانًا ، رؤوس مجمعة مسبقًا مجانًا ، تغطية مجانية ...
• الوثائق تخلصك من وثائق CMake: http://mesonbuild.com/
• لقد وجدت أن التجميع المتقاطع أسهل بكثير
• ميزون لديه طريقة واضحة للقيام بكل شيء

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

آسف لهذا الترويج الذاتي الوقح أدناه ، لكنني أعتقد أن السياق يستجدي ذلك.

لدي سلسلة صغيرة من المقالات حول الميزون الأساسي أكثر أو أقل هنا إذا كان أي شخص فضوليًا (4 مقالات):

• https://medium.com/@germandiagogomez/getting -started-with-meson-build-system-and-c-83270f444bee
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-2-58150354ff17
• https://medium.com/@germandiagogomez/getting -started-with-meson-in-c-part-3-70b9bc419957
• https://medium.com/@germandiagogomez/getting -started-with-meson-part-4-8bceec6149e1

لدي رد (قديم بعض الشيء) على أنظمة الإنشاء في StackOverflow:

https://stackoverflow.com/questions/5837764/autotools-vs-cmake-for-both-windows-and-linux-compilation/24953691#24953691

جمعية البناء الخيرية :)

germandiago هذه كتابة رائعة - لقد كنت أتابع هذه المشكلة لفترة من الوقت وسيكون من الرائع أن أعمل مع godot + CLion ، وهو للأسف CMake فقط.

نعم ، معظم IDE الحديثة هي إما CMake فقط ، و / أو بعض أنظمة Custom Build ، و / أو "المكالمات الأولية" التي تفقد الكثير من الميزات. لقد أصبح CMake حقًا معيارًا ، سواء كان ذلك مستحقًا أم لا.

dorkbox إذا كان بإمكاني الحصول على هذه التغييرات التي أعمل عليها ، فستتمكن بالتأكيد من العمل في سير عمل CLion (cmake + ninja).

تضمين التغريدة

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

أحب استخدام ميزون. إذا قرأت أكثر في الموضوع ، فقد جربت منفذ ميزون ، لكن الأشياء كانت متكاملة جدًا مع Scons في ذلك الوقت. ما زلت أقوم بسحب البرامج النصية الحالية لتوليد الكود لتكون نصوص "قابلة للتنفيذ" منفصلة بحيث إذا لم يكن الانتقال إلى Meson في المستقبل غير وارد. ومع ذلك ، فهو عمل بطيء ، وقد أخذت في كتابة بعض قوالب jinja للمساعدة في إنشاء الكود بحيث يمكن إسقاط scons بالكامل. ومع ذلك ، في حين أن الشوكة العامة الخاصة بي قديمة ، فإن الشوكة التي أمتلكها في المنزل متقدمة قليلاً (وتتم مزامنتها مع مفترق خاص). لسوء الحظ ، تعثر العمل في الطريق ، ولسوء الحظ ، فإن سان دييغو ستسرق المزيد من وقتي. بعد ذلك ، ومع ذلك ، يجب أن أكون حراً في إزالة بعض التجارب المحلية التي أجريها على مفترقتي الخاصة ، وأخيراً أعود إلى قطار godot cmake. أنا ملتزم بالتأكد من أن طلب السحب الكامل يمكن أن يدخل دون حدوث اضطراب كبير في عملية سير العمل الحالية.

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

نعم ، معظم IDE الحديثة هي إما CMake فقط ، و / أو بعض أنظمة Custom Build ، و / أو "المكالمات الأولية" التي تفقد الكثير من الميزات. لقد أصبح CMake حقًا معيارًا ، سواء كان ذلك مستحقًا أم لا.

أداة مفيدة محتملة لاستخدام الميزون مع IDEs:

https://github.com/prozum/meson-cmake-wrapper

يجعل IDE يعتقد أنه يستخدم CMake ، ولكنه يستخدم الميزون بالفعل تحت الغطاء.

بعض المعلومات الأساسية: لقد كنت مؤيدًا كبيرًا لـ CMake لعدة سنوات (10؟) ، لكنني وقعت في حب الميزون هذا العام الماضي أو نحو ذلك. يبدو أن Meson مكتوب بقصد الحصول على ميزات CMake المفيدة أثناء إصلاح / منع العديد من مضايقات CMake. أحد العوائق التي أواجهها حاليًا لاعتماد ميزون في المشروع هو دعم IDE. لقد اكتشفت الأداة المذكورة أعلاه ، لذا ربما سيساعد ذلك.

كل نظام بناء له عيوبه الرئيسية ، أكثر من ذلك ، لا يوجد سبب لتغيير ذلك من الناحية الفنية ، سواء كان ذلك من خلال scons أو autotools أو cmake أو meson أو أيًا كان ما يجعل من النينجا دينك. أعتقد أنه سيكون من الرائع إغلاق جميع أخطاء تغيير نظام البناء الأخرى باعتبارها نسخة مكررة من هذا الخطأ.

<reduz> iFire: no, you did not, all you did was build it but did not port any of the dozens of custom scripts that generate code
<iFire> reduz: the other person worked on the little python script generation on her branch
<iFire> so they directly imported the python env
<iFire> it's workable
<reduz> iFire: that is what everyone said that attempted it, and failed :P
<reduz> there are too many things in there

إثبات خطأ reduz @ slurps-mad-rips :).

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

lazybullfrog لديّ وصول إلى حوالي 5 أجهزة منفصلة لسطح المكتب والعديد من الأجهزة المحمولة. جزء من المنفذ الخاص بي إلى cmake هو التأكد من وجود سلاسل أدوات cmake متاحة لجميع الأنظمة الأساسية الحالية.

@ مسرفة في جنون مزقت هو واحد من هؤلاء Haiku؟ إذا لم يكن الأمر كذلك ، فسأكون على استعداد للمساعدة في الاختبار. شكرا.

جزء من المنفذ الخاص بي إلى cmake هو التأكد من وجود سلاسل أدوات cmake متاحة لجميع الأنظمة الأساسية الحالية.

لا تنس أيضًا أنه إذا كنت بحاجة إلى سلاسل أدوات cmake لمنصة ، فمن المحتمل أن يكون هناك واحد تم إنشاؤه مسبقًا على https://github.com/ruslo/polly وإذا لم يكن موجودًا ، فيجب عليك نشره. :-)

@ slurps-mad-rips كيف كان الحال؟ لقد لاحظت أنك قمت بتحديث الرمز في 14 يناير. لقد حاولت التجميع على Windows ولكن لم أجد pkgconfig.

قررت fire life أن أرمي بعض متبوعين بـ FreeBSD و Haiku (آسف

كان أكبر جزء من العمل / مانع حتى الآن هو استخراج نصوص Python إلى أدوات "قابلة للتثبيت" منفصلة عن Scons ويتم تنفيذها مثل العمليات. كان الاستيلاء الفعلي على التبعيات والإعدادات وما إلى ذلك أسهل بالمقارنة.

@ slurps-mad-rips ، ألقتني الحياة ببعض الكرات المنحنية أيضًا. ربما يجب أن نبدأ فريق بيسبول. 😂

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

أنا في الواقع سعيد لأن كلا النظامين الأساسيين يحظيان بالاهتمام. نتطلع للاختبار قريبا.

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

سأكون على استعداد للمساهمة في ميناء Bazel إذا سارت الأمور على هذا النحو.

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

باعتباري أحد برامج حزم Linux ، فقد رأيت مئات المشاريع مع أنظمة بناء مختلفة. لقد رأيت القليل الذي يحتوي على العديد من أنظمة البناء المتاحة. لم أر مطلقًا أحدًا لم يكن هناك فوضى كاملة ، خاصةً عندما تم المساهمة بأنظمة البناء البديلة لأول مرة من قبل المساهمين "الرجاء إضافة CMake it's so cool" الذين اختفوا بعد ذلك من المشروع ، ولم يزعج المشرفون تحديثه.

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

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

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

هذا ما كنت أفعله مع منفذ CMake الخاص بي. في الوقت الحالي ، يستغرق تغيير عدم التشغيل أو الملف الفردي تحت scons ما يزيد عن 10 ثوانٍ على جهازي الحالي (الذي يحتوي على 64 جيجابايت من ذاكرة الوصول العشوائي ، ومعالج مشابه ، وما إلى ذلك) مع ninja + cm ، تستغرق عملية التكوين + الإنشاء بأكملها وقتًا أقل ، والنينجا ينتهي البناء في أقل من 0.2 ثانية في بنية غير تشغيلية (على النوافذ ، حيث يكون بدء العملية مكلفًا). أنا أيضًا قادر على استخدام أداة sccache من mozilla إذا كانت مثبتة ، وكان ذلك مفيدًا للغاية لتحرير أجزاء الكودجين / تشغيل بناء مُجدد من الصفر للتأكد من عدم اعتماد أي شيء على بيئتي المحلية.

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

لقد عدت لتوي من رحلتي وتمكنت من إنجاز القليل من العمل. في الوقت الحالي ، ما زلت بحاجة إلى نسخ بعض الملفات من تشغيل يدوي ، لكني كنت أقوم بتقطيع المصادر التي تم إنشاؤها مع مرور الوقت. تعد الرؤوس license.gen.h و method_bind.inc هدفي الأكبر حاليًا ، لكنني سأستغرق بضعة أيام للتعامل مع عمل jetlag + قبل أن أتناولها.

(أيضًا فقط ccfire لأنه كان مهتمًا بهذا التقدم قليلاً)

من واقع خبرتي ، فإن Meson متوقف تمامًا عند إنشاء Android على Windows ، ولا يمكنني جعله يعمل على تجميع إحدى مكتبات الجهات الخارجية التي تستخدمها (libepoxy). وأعتقد أنه مرتبط كثيرًا بأشياء المترجم الخرساني.

كل ما أرغب فيه هو نظام بناء يمكنه إنشاء ملفات المشروع وملفات قاعدة البيانات بشكل منفصل عن أمر البناء.

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

حاليًا ، الحل الوحيد القابل للتطبيق لترميز Godot على windows (IDE-wise) هو باستخدام Visual Studio ، وإلا كن مستعدًا لاستخدام محرر نصوص فقط.

Scons هي رائعة وكل شيء ، ولكن عندما يكون لدي 12 خيطًا أساسيًا و 128 غيغابايت من ذاكرة الوصول العشوائي ويجب أن أنتظر أكثر من 12 ثانية على النوافذ لتجميع تغيير سطر واحد (معظم ذلك هو تفكير Scons) ، يصبح الأمر مزعجًا بعض الشيء.

لكن الجانب السلبي الحقيقي لـ Scons (وقد يكون هذا هو كسولي في البحث) هو أنني لا أستطيع تجميع ملفات cpp الفردية. تعد القدرة على تجميع ملفات cpp الفردية دون إنشاء المشروع بأكمله بمثابة معزز ضخم للإنتاجية ومدقق سلامة.

ليست التغييرات الخطية فقط هي التي تستغرق وقتًا ، بل إن معرفة ما إذا كان هناك أي شيء يمكن بناؤه يستغرق وقتًا ...

تشغيل من git-bash:

$ time scons -j24 num_jobs=24 vsproj=true platform=windows
scons: Reading SConscript files ...
Configuring for Windows: target=debug, bits=default
 Found MSVC version 14.2, arch amd64, bits=64
YASM is necessary for WebM SIMD optimizations.
WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] progress_finish(["progress_finish"], [])
[Initial build] scons: done building targets.

real    0m16.082s
user    0m0.000s
sys     0m0.030s

إذا كنت تريد إنشاء ملف هدف واحد فقط ، فحدد ذلك في سطر الأوامر

scons -j24 num_jobs=24 vsproj=true platform=windows <path  to targetfile>/targetfile.obj

أردت فقط أن أضيف أن أحدث إصدار من CMake يضيف بعض الميزات المفقودة التي ذكرها الأشخاص سابقًا كأسباب لعدم استخدامها.
يبني الوحدة: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
رؤوس مجمعة مسبقًا: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

Nosliwnayr كلاهما تم دعمهما من قبل الإضافات لسنوات عديدة ، لقد تم اختبارهما جيدًا وأراد الآن تضمينهما بدرجة كافية. لم تكن هذه أبدًا أسبابًا لعدم استخدام CMake لأنك كنت قادرًا على القيام بالأمرين معًا في CMake لفترة طويلة جدًا.

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

آمل أن يتم تحسين أوقات الترجمة بشكل أكبر ، وأن تكون قادرًا على تجميع كود c ++ قريبًا على الفور دون أي حيل سيكون بمثابة إرسال إلهي - بعد رؤية مدى سرعة تجميع godot ، فأنا أعاني حقًا للعودة إلى المحرك غير الواقعي 4 (تجميعه) ، استغرق مني 45 دقيقة ، ولكن الآن أصبح المحرك منتفخًا بطريقة ما ، ويستغرق الأمر ما يصل إلى 60 دقيقة ، وهو أمر مجنون)

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

تضمين التغريدة
هل يمكننا تجنب الرؤوس المجمعة مسبقًا من فضلك؟ أعتقد أنها قمامة كاملة ، فقط اجعلها بسيطة

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

بعد استخدام المحرك غير الواقعي 4 ، سئمت 20 جيجا بايت من الهراء المجمع مسبقًا ، لا أعتقد أنها تستحق ذلك ، يجب أن يكون هناك نظام أقل غباءًا (المحرك غير الحقيقي 4 ، استغرق ما يصل إلى 60 - 80 جيجا بالنسبة لي ، ليس رائع)

إذا اتجه جودو إلى هذا الاتجاه ، فسأفترض أن المطورين قد فقدوا عقولهم اللعينة

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

أعتقد أن الجهد الذهني المطلوب ، من أجل الدفع في نظام جديد تمامًا ، هو أعلى بكثير من مجرد تحسين ما لدينا بالفعل ، والمترجم الجديد ، قد ينتهي به الأمر إلى الانهيار الوظيفي لأشهر

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

@ RaTcHeT302 - سطر الأوامر المحدد هو إذا كنت تريد صراحة تجميع هدف واحد فقط (في هذه الحالة ملف كائن) (وبالطبع الملفات التي يعتمد عليها)

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

bdbaddog Scons لا تنشئ ملفات بناء المرحلة المتوسطة. يقوم بخطوة "تبعية المشروع" في نفس الخطوة التي يقوم فيها بالتجميع ، ولا يمكن فصلهما.

إنه مثل إخبار CMake بإنشاء ملفات المشروع في كل مرة قبل أن تضغط على أداة البناء الخاصة بك ، سواء كانت MSVC ، أو ninja-build ، أو make ، أو llvm ، أو اختر السم.

إذا قمت بتبديل فروع git ، فلا يمكنني تحديث الاستوديو المرئي بدون إجراء بناء سطر أوامر scons لإعادة إنشاء ملفات .vsproj و .sln المناسبة - وأنا دائمًا ما أقوم بتنظيف تغييرات فرع الإنشاء منذ أن واجهت مشكلات في الماضي.

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

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

عند تحويل مفترقتي إلى CM ، تأكد من أن معظم التعقيد كان في ملفات إنشاء التعليمات البرمجية. فكرة أن البناء معقد هي مغالطة. لا يحتاج البناء إلى scons لأنه معقد. إنه معقد لأنه يستخدم الشمعات.

مع ذلك ، فإن سبب توقفي عن العمل هو أنني التقيت بالمطورين الرئيسيين في GDC في عام 2019 (في GitHub Meetup) وقالوا إنهم ليس لديهم أي نية على الإطلاق للتبديل إلى شيء أكثر قابلية للاستخدام ، مشيرين إلى أنهم يفضلون القيام بذلك البناء بالكامل على نظام التشغيل Linux ، ومما رأيته بالفعل ينتهك اتفاقية ترخيص المستخدم النهائي (EULA) التي تتطلب Apple قبولها لتثبيت أدوات البناء للتجميع المتقاطع.

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

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

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

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

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

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

أشعر كما لو أن نظام الإنشاء الحالي قد تم تحويله بنسبة 100٪ بطريقة التوصيل والتشغيل ، فلن يكون هناك سبب من المطورين لعدم التبديل.

البناء فقط على لينكس غير مجدي. إن امتلاك محرك ألعاب لا يعمل على Windows سوف يردع أي مطور ألعاب جاد.

أود أن يكون لدي انطباع بأن مطوري اللعبة يهتمون بما يكفي لتغيير نظام البناء لإرضاء مستخدميها.

أحد الأسباب التي دفعتني إلى ترك Unreal هو أن المحرك مصمم بشكل أساسي لإنشاء لعبة Blueprint / الواجهة الأمامية. يعد إنشاء الأدوات في وحدات c ++ أمرًا مؤلمًا ومعقدًا للغاية في Unreal.

حتى الآن ، كان الأمر ممتعًا في Godot . إن جعل C ++ يبني بشكل أسرع سيكون إضافة كبيرة للمجتمع.

IIRC يستخدمون Wine لتشغيل أدوات بناء MSVC. ما زلت لا تغير وجهة نظرك ، وأنا أوافق.

البناء فقط على لينكس غير مجدي. إن امتلاك محرك ألعاب لا يعمل على Windows سوف يردع أي مطور ألعاب جاد.

لطالما كان Godot قابلاً للبناء على العديد من الأنظمة الأساسية ، وليس فقط Linux ...

IIRC يستخدمون Wine لتشغيل أدوات بناء MSVC. ما زلت لا تغير وجهة نظرك ، وأنا أوافق.

يتم تجميع إصدارات Windows الرسمية باستخدام MinGW ؛ لا نستخدم WINE لتشغيل MSVC على Linux.

marstaik - إذا قمت بتبديل

لذا حاول:

scons <path to created MSVS project file>/VSPROJECTFILENAME (replace with actual paths and file name which are generated)

يجب أن تكون SCons قادرة على القيام بذلك دون القيام ببناء كامل وأيضًا يجب أن تفعل ذلك بشكل صحيح دون الحاجة إلى القيام بعملية التنظيف أولاً.
(راجع للشغل. أنا مشرف مشروع SCons)

bdbaddog اضطررت إلى إضافة vsproj = صحيح لهذا الأمر ، لكن يبدو أنه نجح

من Godot src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

تحرير: لسبب ما تحتاج إلى إضافة العلامة -j أيضًا ...

bdbaddog اضطررت إلى إضافة vsproj = صحيح لهذا الأمر ، لكن يبدو أنه نجح

من Godot src:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

تحرير: لسبب ما تحتاج إلى إضافة العلامة -j أيضًا ...

الكثير من هذه الأعلام ليست Vanilla SCons ، ولكنها جزء من الطريقة التي تنفذ بها الحزم المختلفة (Godot في هذه الحالة) نظام البناء الخاص بها مع SCons.
سعيد لأنك وجدت طريقة!

لماذا تستخدم SConstruct وتصر على عدم التحول إلى نظام بناء آخر ؟؟؟

tjysdsg تلخص المناقشة أعلاه ذلك جيدًا:

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

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

بشكل عام ، تغيير نظام البناء ليس شيئًا نقبله من المساهمين الجدد. يجب أن يأتي من الداخل ، ويجب على جميع المساهمين الأساسيين رؤيته كتغيير إيجابي حتى يكون له أي معنى. لن نغير نظام البناء لمجرد إرضاء المستخدمين الجدد الذين يحاولون بناء Godot من المصدر ولا يحبون بطريقة ما أنه يتعين عليهم كتابة scons بدلاً من cmake أو meson التي اعتادوا عليها. لن نقبل أيضًا محاولات تقديم نظام بناء جديد اختياري - من التجربة ، أعلم أن هذا يمكن أن يؤدي فقط إلى عدم الاتساق والأخطاء واختلافات الإخراج.

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

وقال @ مسرفة في التعرق جنون مزقت ذلك بشكل جيد.

إنه معقد لأنه يستخدم الشمعات.

و

تمكن إصدار CMake الخاص بي من اكتشاف مجموعة من أخطاء التحليل الثابتة التي أدت إلى العديد من المشكلات ويمكن حلها بسهولة

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

لن يحدث التحول إلى نظام بناء "أكثر برودة" من أجل ذلك

CMake ليس "أكثر برودة" ، إنه المعيار. إذا كنت تستخدمه بالفعل ، فستفهم على الفور السبب.

بالطبع نحن منفتحون على تغيير آرائنا إذا أمكن إدراج مكاسب واضحة (وإظهارها بإثبات عملي للمفهوم) تفوق تكاليف تغيير نظام البناء

لست مقتنعًا بأن أي شخص منفتح على تغيير رأيه. مرة أخرى ، أظهرت @ slurps-mad-rips مكاسب واضحة ، حتى أنها قامت بكل العمل ... لقد تم بالفعل.

إنه لأمر مخز ، يمثل الموقف الرسمي لفريق Godot ، أن تتجاهل تمامًا جهودها في تحسين عملية التنمية.

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

في الجمعة 21 فبراير 2020 الساعة 1:38 مساءً كتب dorkbox [email protected] :

@ slurps-mad-rips https://github.com/slurps-mad-rips قال ذلك جيدًا.

إنه معقد لأنه يستخدم الشمعات.

و

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

من المثير للاشمئزاز أن CMake لا يُعطى اعتبارًا جادًا ، يمكنني ذلك
أعتقد أن من أسباب كثيرة لSCons الخندق، ولكن على وجه التحديد أن يرى CMake
الأخطاء التي لا تجدها Scons تجعل استخدام شيء آخر "يستحق" العناء.

لن يحدث التحول إلى نظام بناء "أكثر برودة" من أجل ذلك

CMake ليس "أكثر برودة" ، إنه المعيار. إذا كنت قد استخدمتها بالفعل ستفعل
فهم على الفور لماذا.

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

لست مقتنعًا بأن أي شخص منفتح على تغيير رأيه. مرة أخرى،
أظهر @ slurps-mad-rips https://github.com/slurps-mad-rips مكاسب واضحة ،
وقد قامت بكل العمل ... لقد تم بالفعل.

إنه لأمر مخز ، يمثل الموقف الرسمي لفريق جودو ، أن
تجاهل تماما جهودها في تحسين عملية التنمية.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/16014؟email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43V89
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

dorkbox - وجد cmake أخطاء تحليل ثابتة؟ أم كان ناتج قاعدة بيانات التجميع من cmake الذي تم تشغيله من خلال أدوات التحليل الثابت الخاصة بـ llvm هو الذي وجدها؟

bdbaddog ، قامت @ slurps-mad-rips بهذا العمل ، وسيكون من الأفضل أن تسألها. (أعتقد أنه سيكون ناتجًا من تحليل llvm الثابت ، لكنني لست الشخص الذي قام بعمل البناء عبر cmake)

تضمين التغريدة

نادرًا ما يكون هناك أي سبب تقني لتغييره.

ماذا عن أدوات التحليل الثابت ودعم ميزات اللغة الحديثة؟

bdbaddogdorkbox لقد قمت ببساطة بتشغيل clang -tidy للبحث عن أشياء مثل "إرجاع الإشارات إلى السكان المحليين غير include-what-you-use للتشغيل أيضًا ، ووجدت عددًا قليلاً من التضمينات غير الضرورية في الرؤوس.

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

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

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

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

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

يبدو أن هناك مغالطة التكلفة الغارقة التي تحدث مع SCons. لماذا لا تستخدم شيئًا أسهل وانسيابيًا وجزءًا بالفعل من أدوات البناء الحالية ، مثل cmake؟

من موقع scons:

بالمقارنة مع السكون ، CMake هو:

• بسرعة
• يتطلب رمزًا أقل للمهام الشائعة
  
  
  
  • يمكن القول إنها أكثر استقرارًا
  
  
  • يدعم الإخراج إلى مشاريع مثل Code :: Blocks و Xcode وما إلى ذلك
  
  

dorkbox - أنا المدير المشارك لمشروع SCons. أنا فقط أراقب الوظائف المطلوبة.

تم إدخال تحسينات على الأداء في الإصدارات القليلة الماضية والإصدارات القادمة.

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

لست على علم بأي مشكلات تتعلق بالاستقرار تؤثر على مشروع godot والتي لم نعالجها. إذا كان هناك أي شيء معلق ، فيرجى إخبارنا بذلك.
(تواصل معنا عبر: https://scons.org/contact.html)

لست متأكدًا من أن cmake تتطلب حقًا رمزًا أقل للمهام الشائعة ، وسأكون مهتمًا بإجراء مقارنة معقولة.

حسنًا ، ما يسعدني غالبًا مع الشمعات هو عدم القدرة على إنشاء شيء قديم
GNU جعل makefile. عدم وجود النينجا - يمكنني التعايش معها.
أيضًا التعامل مع أدوات الترجمة المتقاطعة مثل سلاسل أدوات CMake والأدوات الآلية
قدرات الترجمة المتقاطعة هي نقطة ضعف قوية.
الباقي على ما يرام لأنني لست شخص IDE. IDE الخاص بي هو بيئة UNIX.

يوم الأحد 23 فبراير 2020 الساعة 10:05 مساءً William Deegan [email protected]
كتب:

dorkbox https://github.com/dorkbox - أنا المدير المشارك لمشروع SCons.
أنا فقط أراقب الوظائف المطلوبة.

الإصدارات القليلة الماضية والقادمة كان لها أداء
تحسينات.

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

لست على علم بأي مشاكل استقرار تؤثر على مشروع godot الذي نحن فيه
لم تعالج. إذا كان هناك أي شيء معلق ، فيرجى إخبارنا بذلك.
(تواصل معنا عبر: https://scons.org/contact.html)

لست متأكدًا من أن cmake تتطلب حقًا رمزًا أقل للمهام الشائعة ، سأكون كذلك
مهتم بمقارنة معقولة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/16014؟email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWK3TUL52HS4DFVREXG43VMVB5
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAABPU6UHPX3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.