Lapack: بناء الأنظمة

للإضافة إلى القائمة ، تدعم تصميمات CMake حاليًا (يبدو أنها) خيار إنشاء أجزاء محددة فقط من المكتبة (REAL ، و DOUBLE ، و COMPLEX و / أو DOUBLE COMPLEX) ، بينما لا تدعم إصدارات Makefile-only. (لقد غيرت ملفات Makefiles في النسخة التي نوزعها مع OpenBLAS ويمكنني إنتاج علاقات عامة إذا رغبت في ذلك - سأحتاج إلى إعادة التخصيص لترك بعض التغييرات غير ذات الصلة هنا)

تدعم إصدارات CMake حاليًا (يبدو أنها) خيار إنشاء أجزاء محددة فقط من المكتبة (REAL و DOUBLE و COMPLEX و / أو DOUBLE COMPLEX)

نجح هذا الخيار في آخر مرة جربته (حوالي مايو 2020).

يحتوي CMake build على العديد من الخيارات ، وسأدرج أهمها بالنسبة لي هنا:

• بناء مكتبات مشتركة أو ثابتة
• تمكين أو تعطيل الاختبارات
• مؤشرات 64 أو 32 بت
• يبني الأمثل وتصحيح الأخطاء
• خيارات مكتبة مولد المصفوفة (TMG) ، واستخدام مكتبات BLAS الأخرى ، و BLAS ++ ، و LAPACK ++ ...

فكره جيده. لقد دفعتني عمليات البناء التي تعمل على جهازي باستخدام Make ولكن ليس على ci مع CMake إلى الجنون عدة مرات.

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

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

أظن أنه سيكون هناك العديد من التصحيحات التي تطفو بالفعل (على سبيل المثال في توزيعات Linux التي تحتوي على حزمة lapack) لبناء مكتبات مشتركة باستخدام gmake. لا ينبغي أن يكون معقدًا جدًا لإضافة خيار BUILD_SHARED لجعله مثل BUILD_DEPRECATED الموجود بالفعل (وكلاهما غامض جدًا في CMake build إلا إذا كان المرء يعرف بالفعل أن ccmake و cmake-gui موجودان).

لا ينبغي أن يكون معقدًا جدًا لإضافة خيار BUILD_SHARED لجعله مثل BUILD_DEPRECATED الموجود بالفعل (وكلاهما غامض جدًا في CMake build إلا إذا كان المرء يعرف بالفعل أن ccmake و cmake-gui موجودان).

ليست هناك حاجة للعمل مع ccmake لتعيين أي من هذه الخيارات. يمكنك استخدام سطر الأوامر المماثل للنص البرمجي configure إنشاؤه بواسطة autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

يمكنك بالتأكيد ، وجهة نظري هي أنه لا توجد وثائق واضحة باستثناء قراءة CMakelists.txt (بينما يشير README إلى ملفات make.inc المكونة مسبقًا لـ gmake). يعرض ccmake و cmake-gui قائمة بالخيارات المتاحة ، ولكن سيتم فقدها على أي شخص جديد لـ cmake.

إذا كتبنا وثائق حول كيفية استخدام CMAKE ، فيمكننا استخدامي كمستخدم لخنزير غينيا لأنني لم أستخدم CMAKE مطلقًا.

عند قراءة المحادثة بأكملها ، أشعر أن Makefile موجود في LAPACK هناك فقط من أجلي. ؛)

حسنا انا لا اعرف.

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

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

الكل: أرجو إبداء رأيك في هذا الموضوع.

يبدو أن معظمنا يرغب في (1) إزالة الميزون وإزالته ؛ (2) الانتقال إلى CMAKE فقط ؛ (3) أضف بعض الوثائق الجيدة حول كيفية استخدام CMAKE. تمام معاي.

سأرسل بعض رسائل البريد الإلكتروني إلى مسؤولي صيانة الحزم الآخرين هنا وهناك لسؤالهم عن أداءهم وما هو رأيهم في هذه المسألة.

@ martin-frbg: كيف يتم ذلك في OpenBLAS؟

يحتوي OpenBLAS على Makefiles كنظام بناء "تقليدي" "معروف للعمل" ، و CMAKE كبديل أصلاً يساهم به المستخدم والذي لا يزال ينذر بتحذير بأن الملفات التي ينشئها قد لا تتوافق تمامًا مع ما يمكن أن يفعله إنشاء Makefile.
لا أحب CMAKE كثيرًا ، لكنني تعلمت إنشاء ملفات بناء cmake (على الرغم من أنها ربما تكون غير تقليدية في بعض الأحيان). في رأيي ، يجب أن تظل ملفات Makefiles (وأعتقد أن gmake لا يزال أكثر انتشارًا من cmake). لا أعرف تاريخ دعم الميزون - _if_ كانت هذه مساهمة لمرة واحدة "ألقيت فوق السياج" ولا يعرفها أحد أو يهتم بما يكفي لتحديثها ، أعتقد أنه لا فائدة تذكر من الاحتفاظ بها.

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

تم هبوط مبنى Meson بالمظلة في LAPACK في PR # 311.

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

لقد تواصلت مع therault . شكراtherault!

يستخدم Open MPI فقط autoconf (auto، autoconf، config، Makefiles).

بالنسبة إلى PaRSEC و DPLASMA ، نحن نستخدم CMake فقط ، ولمساعدة المستخدمين الذين اعتادوا على التهيئة ، أنشأabouteiller نصًا يستخدم بنية التكوين ويستدعي CMake باستخدام بناء الجملة الخاص به.

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

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

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

اليوم ، أنا أؤيد CMake لسبب واحد: يقوم CMake بعمل جيد في إنشاء ملفات Ninja بدلاً من Makefiles. يجمع Ninja PaRSEC مرتين إلى ثلاث مرات أسرع من Make -j. الآن ، ربما يمكن للتكوين / autoconf أيضًا إنشاء ملفات Ninja ، لم أحاول أبدًا ... إذا لم تجرب النينجا من قبل ، وإذا كان LAPACK يحتوي على إصدار CMake ، أقترح عليك تجربة cmake -G Ninja (بعد تثبيت Ninja على جهازك). للترجمة ، يمكنك استدعاء "ninja" في الدليل حيث قمت بتنفيذ cmake بدلاً من "make". سترى ، هذا مذهل :)

يسعدني أن أساهم ببرنامج نصي للغراء من التكوين إلى cmake في LAPACK إذا كان هذا شيئًا تهتم به.
(للتوضيح ، هذا البرنامج النصي لا يعتمد على autoconf / m4 ، إنه برنامج نصي بسيط يحول configure --with-feature=value إلى مكالمة إلى cmake -DFEATURE=value ، مع القليل من الصقل).

لا يستخدم LAPACK حتى التكوين - وأنا أوافق على أنه قد يكون من الصعب الحفاظ على نظام قائم على autoconf / automake / تكوين متزامن مع cmake ، مع "تطور" الأدوات الآلية نفسها باستمرار وتعتمد على وحدات ماكرو m4 وما إلى ذلك.

أنا قلق من الانتقال إلى CMAKE لأنني لا أعرف فقط كيفية استخدامه ، ولا أعرف كيف أحافظ عليه.

هذا سبب رئيسي للالتزام بـ Makefiles.

الكل: أرجو إبداء رأيك في هذا الموضوع.

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

CMake هو نظام بناء محمول مع بناء جملة بسيط وبنيات قابلة للتكوين بالكامل. يمكن للمرء تعيين خيارات خاصة بالملف أو خاصة بالمترجم أو خاصة بالهدف (على سبيل المثال ، لتمكين الوظائف غير الموجودة في مكتبة C القياسية مثل gethostname() ). CMake لديه إدارة ملف كائن قوي ؛ يتيح لك هذا الاستمرار في كتابة make لتحديث الإصدارات الخاصة بك حتى إذا قمت بتبديل فروع git. يتفاعل CMake بشكل جيد مع بقية نظام UNIX البيئي: يمكنك استدعاء البرامج العشوائية والعمل وفقًا لمخرجاتها. على سبيل المثال ، يمكنك الاتصال بـ pkg-config لتحديد موقع الحزم الأخرى.

كانت المرة الأولى التي استخدمت فيها CMake في عام 2016 واستخدمتها باستمرار منذ ذلك الحين لإنشاء كود لأنظمة Linux و Mac و iOS و Android ، على هياكل مجموعة التعليمات x86 و x86-64 و armv7 و aarch64. إنه متاح في جميع توزيعات Linux الرئيسية وعلى جميع أجهزة الكمبيوتر العملاقة التي يمكنني الوصول إليها (Grid 5000 و Jean Zay و JUWELS و GRICAD و Eagle II). عادةً ما يكون لأجهزة الكمبيوتر العملاقة إصدارات متعددة متاحة بما في ذلك الإصدارات القديمة والإصدارات الحديثة جدًا (3.18+). النظام الأساسي الوحيد الذي عانيت فيه من توفر CMake هو CentOS 7 ولكن يمكنك دائمًا تنزيل تار CMake واستخدام نص تمهيد التشغيل داخل كرة القطران لإنشاء CMake باستخدام GNU Make فقط.

CMake يعمل فقط من أجلي.

تجربتي مع أنظمة البناء الأخرى هي كما يلي:

• Bazel: خنزير ذاكرة ضخم ، من المستحيل تشغيله على Raspberry Pi بسعة 1 جيجابايت من الذاكرة ، ويصر على بناء جميع التبعيات ، وربط كل شيء بشكل ثابت
• Autotools: كمطور ليس لديه خبرة ، كمستخدم ، فإن البرنامج النصي configure مناسب جدًا لأنه يمكن أن يعرض لك جميع الخيارات المتاحة (CMake يفعل ذلك باستخدام ccmake فقط بعد تشغيل cmake بمجرد).

اليوم ، أنا أؤيد CMake لسبب واحد: يقوم CMake بعمل جيد في إنشاء ملفات Ninja بدلاً من Makefiles. يجمع Ninja PaRSEC مرتين إلى ثلاث مرات أسرع من Make -j.

عظيم ، لم يستطع Ninja تجميع Fortran في الماضي ، راجع. ninja # 1265 ، على سبيل

أود بالتأكيد أن أقول إن ملفات makefiles العادية أسهل وكافية في هذه الحالة.
صيانة البرامج في مجموعة HPC أشعر بخيبة أمل كبيرة من استخدامات Cmake.

1. يواجه المطورون صعوبة في اتباع مخططات التسمية القياسية مما يجعل عملية البناء صعبة بسبب الإفراط في قراءة الوثائق. كل حزمة تفعل بعض "تعديل" الأسماء التي تناسب مشاريعهم. وبالتالي ينتهي الأمر في مخططات التسمية غير القياسية. (صحيح بعض الشيء لـ autoconf + ، ولكن هنا تم توحيد الأشياء أكثر)
2. عندما تتعطل الأشياء في cmake ، فإنها تتطلب خبيرًا في cmake لتصحيحها ، ما زلت أجد صعوبة كبيرة في تصحيح الأخطاء ... :(
3. يصعب استخدام ملفات التكوين (لا يوجد make.inc ) ، وهذا يفرض تحديد جميع خيارات المبنى في سطر الأوامر في وقت الإنشاء.

من ناحية أخرى ، يقوم cmake أيضًا بأشياء لطيفة:

1. دعم أسهل للنوافذ
2. المزيد من المعالجة التلقائية للتبعيات وإدراج ملفات cmake لمشاريع أخرى (هذه فائدة جيدة)

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

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

أشعر وكأنني في وضع مشابه لأنك langou .

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

ومع ذلك ، لا يمكنني تجاهل جميع الميزات الرائعة التي يبدو أن cmake توفرها. في النهاية ، أعتقد أن إما CMake أو gmake سوف يعملان بشكل جيد. نحن فقط بحاجة لاختيار واحد.

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

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

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

في مشروع SciPy ، سنحاول أيضًا استخدام CMake أو Meson في مرحلة ما نظرًا لأن Python distutils تم إيقاف تشغيله.

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

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

فكرة واحدة للتحايل على مشكلة أنظمة البناء المتعددة هي:

• قم بإنشاء المزيد من التكوينات في CI بحيث تغطي جميع أنظمة البناء المدعومة. بهذه الطريقة نضمن أن جميع أنظمة البناء تعمل بالميزات الأساسية.
• اعرض الكل واقترح استخدام أحد أنظمة البناء في README. مثال: _ نقترح استخدام CMake إذا كنت بحاجة إلى إنشاء مكتبات مشتركة وثابتة ، ... _ ، كما هو مذكور بواسطة @ martin-frbg و @ christoph-conrads و @ thijssteel في هذا الموضوع. (لم أكن أعلم أن هناك نظام بناء ميسون في المستودع. أعتقد أنه يجب علينا إما إضافته في README أو التوقف عن الحفاظ على هذا الخيار.)

بقدر ما أفهم ، فإن المشكلة المتعلقة بعلامة recursive تتعلق بإجراءات الاختبار xeigtstz (انظر https://github.com/Reference-LAPACK/lapack/issues/335# إصدار - 485021575). عندما يتم إصلاح هذه المشكلة ، فإن رأيي هو أننا سنقرر أي منهما

1. أضف العلم إلى تكوين CMake الافتراضي وأي مكان آخر مفقود ، أو
2. إزالة العلم من ملفات make.inc.* .

سوء فهم طفيف wrt -frecursive أعتقد - هذا مطلوب من أجل الأداء الصحيح للكود متعدد مؤشرات الترابط ، لذلك لا ينبغي إزالته من ملفات البناء بشكل عام. ومع ذلك ، فإن أحد الآثار الجانبية هو أنه يضع المصفوفات المحلية على المكدس ، والتي تصادف أن تكون كبيرة للغاية في حالة xeigtstz. قد يبدو أن إزالة هذا الخيار من ملف TESTING / EIG Makefile (فقط) يساعد في الحالة البسيطة ، ولكن يبدو أنه ضمني عند التحويل البرمجي باستخدام "-fopenmp" لذلك لا يعد هذا حلاً عامًا لمتطلبات الحد الأقصى غير العادية لهذا الاختبار.

لذلك هذا هو السبب.
أوافق على أن LAPACK عبارة عن مكتبة "بسيطة" - مجرد امتلاك نظام تصنيع يجب أن يكون كافيًا ، وقد كان كافيًا لفترة طويلة.
لكن لكن .. هناك Windows .. وفقط بسبب Windows ، كان علينا إحضار cmake. في الأصل ، عمل الأشخاص من CMake على التكوين ، لكن الآن أعتقد أننا وحدنا ، ومثل langou ، نحن لا
الآن معظم البرامج التي تعتمد على LAPACK تستخدم Cmake ونحن نعلم من تعليقات المستخدمين لدينا ، أنهم يحبونها.

لذلك إذا كان علينا اختيار نظام بناء واحد: يجب أن يكون هذا Cmake ... لسوء الحظ في الوقت الحاضر ولكن لحسن الحظ للمستقبل.

تصويتي: اتباع نصيحةabouteiller و therault ولديك نظام بناء واحد فقط ، وبالتالي cmake.

الآن معظم البرامج التي تعتمد على LAPACK تستخدم Cmake ونحن نعلم من تعليقات المستخدمين لدينا ، أنهم يحبونها.

لقد فتحت هذه المشكلة واقترحت أن يكون لدي نظام بناء واحد فقط. كان افتراضي أن مهارات Makefile و CMake موزعة بالتساوي. الرجاء تصحيح ما إذا كنت مخطئًا ولكن انطباعي هو أن هذا ليس صحيحًا بين المساهمين العاديين في LAPACK : يبدو أن ملفات Makefiles شائعة ويبدو أن معرفة CMake ليست قوية. علاوة على ذلك ، بعد يومين من المناقشة ، يبدو أن أعلام -frecursive هي الفرق الوحيد بين بناء CMake و Makefile وحقيقة أن CMake هو المستخدم الوحيد في Travis CI. ليس من المنطقي فرض نظام بناء واحد يجعل المستخدمين سعداء إذا أبعد المساهمين الأساسيين.

(يستند حكمي بشأن من هو المساهم المنتظم إلى النظر في الصفحات الخمس الأولى من طلبات السحب المقبولة.)

موافق .. راجع للشغل ، العلامات العودية موجودة في تكوينات CMake و Makefile الافتراضية مع # 492. لذلك ، أعتقد أننا نحتاج فقط إلى تضمين Makefile build في Travis CI.

يخفف PR # 500 من التناقضات بين أنظمة إنشاء Makefile و CMake المذكورة هنا. انظر https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

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