Godot: बिल्डसिस्टम को मेसन या किसी अन्य बिल्ड सिस्टम में ले जाने पर विचार करें

मैं जो समझता हूं, उसके लिए बिल्डसिस्टम टूलिंग प्रदान करनी चाहिए:

• क्रॉस-संकलन (एक ही मेजबान मंच से हर संभव लक्ष्य मंच के लिए संकलन)।
  
  
  
  • "संभव" से मेरा मतलब है कि मेजबान इसे अनुमति देता है (इसलिए मैकोज़ और आईओएस केवल मैक मशीन में और ओएसएक्सक्रॉस के साथ लिनक्स से संभव है)।
  
  
• फ़ाइलें उत्पन्न करने का एक तरीका (पीओ से अनुवाद, जीएलएसएल से शेडर कक्षाएं, एक्सएमएल से दस्तावेज़ीकरण डेटा)।
  
  
  
  • स्कैन जानता है कि जेनरेट की गई फाइलें निर्भरताएं हैं, इसलिए उन्हें बदलना प्रासंगिक फाइलों के पुनर्निर्माण को ट्रिगर करता है। इस पर भी विचार किया जाना चाहिए।
  
  
• लक्ष्य के भीतर एकाधिक लक्ष्य और विकल्प (लक्ष्य = डिबग/रिलीज़_डीबग/रिलीज़, आर्किटेक्चर x86 या ARM के रूप में, 32 या 64 बिट)।
• अतिरिक्त लक्ष्यों को बनाने/सक्षम करने के विकल्प (gdnative आवरण, कोई मोनो गोंद, सक्षम/अक्षम: मॉड्यूल, ड्राइवर, पदावनत सुविधाएँ, आदि, अंतर्निहित कोड का उपयोग करके स्थिर रूप से संकलित करने के लिए libs सेट करें या प्रत्येक के लिए सिस्टम libs का उपयोग करें। एक व्यक्तिगत रूप से)।

मैं मेसन को नहीं जानता, लेकिन अगर यह ऊपर सब कुछ प्रदान करता है तो यह ठीक होना चाहिए (अगर मैं कुछ नहीं भूल गया)। बेशक, किसी को मेसन में बिल्डसिस्टम को फिर से लिखने के कष्टदायी दर्द से गुजरना होगा और फिर टूलींग और बिल्ड समय दिखाना होगा कि गोडोट के लिए स्कैन्स की तुलना में प्रभावी रूप से बेहतर है।

ध्यान दें कि कुछ तृतीय-पक्ष निर्भरता को गोडोट के साथ संकलित करने के लिए एक पैच की आवश्यकता होती है। मैंने देखा कि रैप में पैच सपोर्ट है, लेकिन ऐसा लगता है कि पैच डाउनलोड करने के लिए कहीं उपलब्ध होना चाहिए, जबकि मुझे लगता है कि अगर वे अभी भी रिपोजिटरी का हिस्सा हैं तो इसे प्रबंधित करना आसान है। इसके अलावा, उनमें से कुछ को विशेष संकलन झंडे की आवश्यकता होती है जिन्हें पूरे निर्माण पर लागू नहीं किया जाना चाहिए।

मुझे लगता है कि इस तरह का प्रूफ-ऑफ-कॉन्सेप्ट बहुत मूल्यवान होगा क्योंकि

• यह हमें एक बेहतर विचार देता है यदि नया बिल्ड सिस्टम हमारी जरूरत की हर चीज को संभालता है और यह कितनी अच्छी तरह करता है
• यह हमें अमूर्त डेटा के बजाय चर्चा करने के लिए ठोस देता है

दूसरे बिंदु के लिए, इसका मतलब है कि हम गोडोट के लिए निर्माण गति में अंतर देख सकते हैं, हम देख सकते हैं कि हमारी बिल्ड स्क्रिप्ट कितनी आसान (या अधिक जटिल) हो जाती है, और हम शिक्षित बनाने के बजाय चुनाव करने के लिए मतभेदों की तुलना अधिक आसानी से कर सकते हैं यह इस आधार पर अनुमान लगाता है कि यह क्या पेशकश कर सकता है।

--

अब, व्यक्तिगत रूप से, मुझे कहना होगा कि मैं न तो इसके पक्ष में हूं और न ही इसके खिलाफ, लेकिन मुझे लगता है कि पूरे निर्माण प्रणाली को बदलने के बजाय (या पहले?) पीछा करने के लिए और अधिक कम लटके हुए फल हैं। विशेष रूप से इस महत्वपूर्ण समय पर, जहां 3.0 सुनिश्चित करने के लिए जितना संभव हो उतने हाथों की आवश्यकता होती है और पहले पैच संभव सर्वोत्तम आकार में होते हैं। लेकिन अगर हम बिल्ड सिस्टम में सुधार करना चाहते हैं, तो मैं CI बिल्ड टाइम और मोनो बिल्ड स्थिति की परेशानी को देखूंगा। (मुझे लगता है कि इन akien की कार्यसूची / aggrievances की सूची में हैं?)

इसके अलावा, विंडोज पर खराब समानांतर बिल्ड चूसते हैं, लेकिन यह व्यक्तिगत रूप से अच्छा-अच्छा-अगर-यह-निश्चित आधार पर अधिक है।

टीएल; डॉ:

• मैं सहमत हूं कि स्कैन दस्तावेज/संसाधनों की कमी है, बिल्ड स्क्रिप्ट आसान पाइथन कुछ हद तक विरोध करती है, आईएमओ
• एक नए-ईश योगदानकर्ता के रूप में, गोडोट बिल्ड सिस्टम सेटअप के लिए कम से कम कष्टप्रद था, पहले सफल संकलन के लिए वास्तव में कम समय
• मैं इसके बजाय जितना संभव हो सके 3.0/3.1 में सुधार पर खर्च किए गए प्रयासों को देखना चाहता हूं और
• बेहतर CI बिल्ड समय और आसान मोनो बिल्ड अधिक महत्वपूर्ण हो सकता है

मेरी राय। :)

मैं पूरी तरह से विश्वास करता हूं कि वहां 3.0 प्राप्त करना और निम्नलिखित रिलीज (3.0.1, 3.1) पर ध्यान केंद्रित करना रिकॉर्ड के लिए इस पर प्राथमिकता लेना चाहिए।
मैं जानता हूँ कि क्यों लोग buildsystems पर काम करना पसंद नहीं है (यह वास्तव में केवल अन्य डेवलपर्स / विशेष रूप से तकनीक की समझ रखने अंत उपयोगकर्ताओं के लाभ के लिए है, क्योंकि - जो संयुक्त राष्ट्र महत्वपूर्ण नहीं है, यह devs 'और योगदानकर्ताओं के जीवन को आसान बनाने के लिए फ़ायदेमंद साबित , लेकिन अंततः अंतिम उपयोगकर्ताओं की खुशी ही लक्ष्य है) और यह पूरी "अवसर लागत" चीज़ है, अर्थात। जब निर्माण प्रणाली में सुधार पर खर्च किया गया समय (या खो गया/बर्बाद, जो आप पूछते हैं उसके आधार पर) परियोजना को बेहतर बनाने पर खर्च किया जा सकता है। (जब तक आप मेरे जैसे नहीं हैं और वास्तव में चीजों के सी ++ पक्ष पर काम नहीं कर सकते हैं।)

और अंत में, स्कैन वास्तव में "बस काम करता है" जो कि अधिकांश डेवलपर्स के लिए शायद काफी अच्छा होगा, इसलिए यह ऐसा कुछ है जो मुझे आशा है कि अंततः होता है, मैं इसके लिए 3.1 या यहां तक ​​​​कि 3.2 के लिए अपनी सांस नहीं रोक रहा हूं, अगर यह वास्तव में शुरू करने के लिए काम करने के लिए पर्याप्त समर्थन प्राप्त करता है।

यह सब कहा, मैं इस सप्ताह के अंत में अपने कांटे में पीओसी को किकस्टार्ट कर सकता हूं, जो उस पर प्रगति का पालन करने के इच्छुक हैं (और संभवतः मेरी मदद करें, क्योंकि मेरे पास बिल्ड सिस्टम लिखने का एक बड़ा अनुभव नहीं है), लेकिन मैं इसके लिए कुछ समय के लिए पुल अनुरोध नहीं खोलूंगा।

मैं वास्तव में स्कैन को धीमा होने के लिए नहीं ढूंढता, और इसकी लचीलापन (जिसका हम लाभ उठाते हैं) शायद किसी और चीज से बेजोड़ है। स्कैन भी बेहद सिद्ध हैं, मुझे लगता है कि यह कभी भी निर्माण को खराब नहीं करता है।

ईमानदारी से, जब तक कोई स्वयंसेवक पूरे निर्माण प्रणाली को फिर से लिखना नहीं चाहता (न केवल अवधारणा का प्रमाण), और यह दिखाता है कि यह या तो सरल (बहुत कम कोड) या बहुत तेज़ है , मैं कुछ और भी नहीं मानता, यहां तक ​​​​कि थोड़ा भी नहीं।

अब, व्यक्तिगत रूप से, मुझे कहना होगा कि मैं न तो इसके पक्ष में हूं और न ही इसके खिलाफ, लेकिन मुझे लगता है कि पूरे निर्माण प्रणाली को बदलने के बजाय (या पहले?) पीछा करने के लिए और अधिक कम लटके हुए फल हैं।

यह वास्तव में इस परिवर्तन के लिए हानिकारक नहीं है। मेरा मतलब है, अधिकांश गोडोट योगदानकर्ता खाली समय पर काम करते हैं और जो चाहते हैं उस पर काम करते हैं। @NullConstant के मामले में ऐसा लगता है कि या तो "यह करें या कुछ भी न करें" (यह नहीं कह रहा है कि आप चीजों को ठीक नहीं करना चाहते हैं, बस वास्तविक सी ++ कोड बेस के साथ काम करना मुश्किल है और कुछ अपरिचित पर बग शिकार है), इसलिए ऐसा करना सामान्य तौर पर अच्छी बात है।

साथ ही, "करने के लिए बेहतर चीजें हैं" तर्क आईएमओ कुछ भी नहीं करने का तरीका है। बेशक कुछ भी तब तक मर्ज नहीं किया जाएगा जब तक हमें विश्वास नहीं हो जाता कि यह सामान नहीं तोड़ेगा और रिलीज के करीब नहीं किया जाएगा। मैं मानता हूं कि और भी महत्वपूर्ण चीजें हैं, लेकिन इसका मतलब यह नहीं है कि इसे शुरू नहीं किया जा सकता है।

बात यह है कि इस पर काम करने वाले को यह काम अकेले करना पड़ सकता है। निश्चित रूप से विशिष्ट प्रश्नों का उत्तर मुख्य देवों द्वारा दिया जा सकता है, लेकिन इससे अधिक कुछ नहीं होगा। यही कारण है कि स्कैन को कभी भी प्रतिस्थापित नहीं किया गया था: कोई भी अब तक हाथों को गंदा नहीं करना चाहता था। जैसा कि मैंने पहले बुलेट के बारे में कहा था: किसी को इसे काम पर लाना होगा और यह साबित करना होगा कि यह संभव और बेहतर है, अन्यथा हम यथास्थिति के साथ रहेंगे।

मुझे लगता है कि स्कैन हालांकि धीमा है। बहुत धीमा नहीं है, लेकिन प्रगति की स्थिति और कैश जैसी चीजें इसे पुनर्निर्माण के लिए धीमा कर देती हैं (कैश से पढ़ने के लिए डिस्क I/O का उपयोग करके इसे धीमा कर देता है), इसलिए पुनर्निर्माण करते समय मैं उन्हें अक्षम कर देता हूं। काम शुरू करने में थोड़ा समय लगता है, उसके बाद यह काफी तेज होता है।

मुझे नहीं पता कि मेसन काफी तेज होगा या नहीं, लेकिन अगर कोई कोशिश करने को तैयार है तो मैं इसके खिलाफ नहीं हूं।

ओह यकीन है, अगर कोई इसे करने के लिए समय लेता है और दिखाता है कि यह वारंट स्विचिंग के लिए काफी बड़ा सुधार है, तो मैं इसके लिए तैयार हूं :)

जैसा कि मैंने कहा, मैं वास्तव में C++ बग का शिकार करने या उस मोर्चे पर नई सुविधाओं को जोड़ने के लिए सुसज्जित नहीं हूं, इसलिए मैं इसके बजाय ऐसा करने के लिए ठीक हूं।

मुझे लगता है कि यह मुझे (और/या भविष्य में इस पर काम करने वाला कोई और) एक बहुत साफ, दो गुना लक्ष्य तक पहुंचने के लिए देता है:

• गोडोट को मेसन के साथ शुरू करने के लिए किसी भी रूप में संकलित करें
• इस समय स्कैन जितना आसान हो उतना आसान बनाएं, संभवतः इससे भी अधिक (गति में सुधार करके)

और मुझे लगता है कि स्कैन की गति भयानक-भयानक नहीं है (बिल्ड प्रक्रिया के समय का बड़ा हिस्सा वास्तविक लिंकिंग और संकलन से है, इसलिए बिल्ड सिस्टम के ऊपरी हिस्से से मंदी कुछ हद तक नगण्य है), लेकिन यह निश्चित रूप से में सुधार किया जा सकता है, और मेसन को एक विकल्प के रूप में पेश करना बस यही सुधार हो सकता है। हम देखेंगे।

सबसे बड़ा मुद्दा शायद शेडर्स जैसे ऑटोजेनरेटिंग कोड के लिए पाइथन बिल्ड स्क्रिप्ट को बदल रहा है, ऐसा नहीं लगता कि मेसन में ऐसी सुविधा है।

और मेसन को एक विकल्प के रूप में पेश करना बस यही सुधार हो सकता है। हम देखेंगे।

यह एक विकल्प नहीं होना चाहिए, या तो हम इसके पास जाते हैं यदि यह स्पष्ट रूप से बेहतर है, या हम इसे पेश भी नहीं करते हैं। दो बिल्ड सिस्टम का समर्थन करना पागल है।

ठीक है, यह उचित है।

मैं अगले कुछ दिनों/सप्ताहों में इसे हैक करना शुरू कर दूंगा, देखें कि यह कहीं भी जाता है और क्या यह वास्तव में पीछा करने लायक प्रयास है (भले ही मैं पूरे समय इस पर काम करने वाला एकमात्र व्यक्ति हूं)।

अगर मुझे कुछ भी प्रस्तुत करने योग्य (बेंचमार्क की तरह) मिलता है तो मैं वापस रिपोर्ट करूंगा।

हालांकि, मेसन नहीं, मैं आने वाले हफ्तों में यह देखने के लिए एक परीक्षण करूंगा कि एमएसवीसी के तहत विंडोज़ 64 बिट के लिए बेज़ल के तहत गोडोट बनाने में क्या लगता है।

बेज़ल एक अन्य प्रणाली है जिसका लाभ एक छोटा निर्माण विवरण और तेज़ निर्माण है। साथ ही इसका रखरखाव Google द्वारा किया जाता है इसलिए यह कहीं नहीं जा रहा है।

वैसे भी, मैं इसे सत्यापित नहीं कर सकता, लेकिन यह बहुत संभावना है कि गोडोट बनाने के लिए खर्च किए गए कम्प्यूटेशनल समय का 99% संकलक में खर्च किया जाता है। इसलिए भले ही बिल्डिंग सॉफ्टवेयर का ओवरहेड कोई नहीं था, इससे बिल्ड टाइम में 1% की कमी आएगी। यहां तक ​​​​कि 5% की कमी भी इसके लायक नहीं होगी, जब तक कि यह कम कोड और अधिक विश्वसनीयता की अनुमति न दे (या यदि मैं गलत साबित हुआ हूं :))।

एक स्वच्छ क्लोन की कच्ची निर्माण गति के लिए, मुझे संदेह है कि इसका कोई महत्वपूर्ण अंतर होगा। लेकिन यह महत्वपूर्ण हो सकता है यदि आप पुनर्निर्माण गति पर विचार करें। स्कैन हमेशा बहुत सारे सामान का पुनर्निर्माण करता है जो कि जब मैं एक नई प्रतिबद्धता (विशेष रूप से ओपनएसएसएल और बुलेट, जो दोनों बड़े पुस्तकालय हैं और निर्माण के लिए कुछ समय लेते हैं) को खींचते समय नहीं बदला गया था।

जैसा कि मैंने पहले कहा था, स्कैन शुरू करने में धीमा है (वास्तव में संकलन शुरू करने से पहले कुछ सेकंड लगते हैं)। यदि आप पूरे स्रोत का निर्माण कर रहे हैं जो नगण्य है, लेकिन यदि आपने केवल एक पंक्ति बदल दी है और परीक्षण के लिए संकलन कर रहे हैं, तो यह वर्कफ़्लो में काफी सुधार कर सकता है (जो आईएमओ बिल्ड सिस्टम में सबसे ज्यादा मायने रखता है: कोड के साथ काम करने वाले लोगों की सहायता करें) . तो 10 मिनट के निर्माण में 5s की कमी अप्रासंगिक है, लेकिन 10s के पुनर्निर्माण में 5s की कमी एक बड़ा सुधार है।

लेकिन मैं मानता हूं कि इस संबंध में किसी भी बदलाव को साबित करने के लिए बहुत परीक्षण किया जाना चाहिए। जैसा कि @reduz ने कहा,

बेज़ल एक अन्य प्रणाली है जिसका लाभ एक छोटा निर्माण विवरण और तेज़ निर्माण है। साथ ही इसका रखरखाव Google द्वारा किया जाता है इसलिए यह कहीं नहीं जा रहा है।

यहां तक ​​​​कि "Google ने बंद की गई चीजें" की विकिपीडिया श्रेणी भी बढ़ रही है। :)

@mhilbrunner नहीं, यह अभी भी बनाए रखा है https://github.com/bazelbuild/bazel

उनका कहना था कि सिर्फ इसलिए कि Google ने इसे बनाया है, इसका मतलब यह नहीं है कि यह लंबे समय तक रहेगा।

चूंकि हमने खेल के विकास के लिए सी # को अपनाया है, इसलिए हम केक जैसे कुछ भी कोशिश कर सकते हैं। हालांकि मैंने इसे स्वयं नहीं किया है, इसलिए मुझे इसमें दिलचस्पी है कि उस पर आपके क्या विचार हैं। एक बात के लिए, कम से कम, स्क्रिप्ट पायथन की तुलना में तेजी से चलती हैं।

चूंकि हमने खेल के विकास के लिए सी # को अपनाया है, इसलिए हम केक जैसे कुछ भी कोशिश कर सकते हैं।

मुझे यकीन नहीं है कि गोडोट को संकलित करने के लिए मोनो इंस्टॉलेशन की आवश्यकता है, यह एक अच्छा विचार है, क्योंकि गोडोट ज्यादातर सी ++ प्रोजेक्ट है और इसे सी # समर्थन के बिना संकलित किया जा सकता है।

मेसन या सीएमके (निंजा जनरेटर के साथ) द्वारा प्रस्तुत प्रदर्शन का स्तर गोडोट के उद्देश्यों के लिए पर्याप्त से अधिक होना चाहिए।

@Calinou आप शायद सही हैं, हालांकि ऐसा लगता है कि हर कोई सी #

संपादित करें:

स्पष्ट करने के लिए, गोडोट बनाने के लिए मोनो फ्रेमवर्क को स्थापित करने की आवश्यकता मेरे लिए उतनी बुरी नहीं है, क्योंकि तथाकथित एएए गेम इंजनों को अधिक डिस्क स्थान की आवश्यकता होती है:

• गोडोट <50MB
• मोनो सपोर्ट वाला गोडोट (<50MB) + मोनो फ्रेमवर्क (~350MB) = ~400MB
• अवास्तविक ~ 20GB
• एकता ~ 10GB
• क्रायइंजिन ~8GB

इसके अलावा, हम डिफ़ॉल्ट रूप से संपादक में मोनो समर्थन को हार्डकोड कर सकते हैं और यह पता लगाने के लिए कुछ तर्क हैं कि रनटाइम पर सी # स्क्रिप्टिंग का समर्थन करना है या नहीं, और मोनो फ्रेमवर्क या उपयुक्त निर्यात टेम्पलेट्स के लिए पूछें।

मुझे सीएमके पसंद है, और मेसन अच्छा दिखता है, लेकिन मैं इस लेख से सहमत हूं: http://www.rojtberg.net/1481/do-not-use-meson।

मुझे गोडोट को मेसन ले जाने के लिए फुटवर्क करने में बहुत दिलचस्पी है। वर्तमान में केवल एक चीज जो मुझे गोडोट में योगदान करने से रोक रही है (और उसका उपयोग कर रही है) वह है स्कैन्स। मुझे इसे सालों पहले इस्तेमाल करना पड़ा था, और मैंने अपने पूरे जीवन में कभी भी अधिक दर्दनाक वृद्धिशील विकास अनुभव नहीं किया है।

ऊपर दिए गए लेख में बहुत सारे स्ट्रॉमैन तर्क हैं, यह तर्क देते हुए कि सीएमके पहले से मौजूद है और हमें इसका उपयोग करना चाहिए। मेसन की बिल्ड फाइलें पढ़ने में बेहद आसान हैं, और पायथन के करीब एक सिंटैक्स का उपयोग करती हैं। रूपांतरण त्वरित हो सकता है। मैं इस धागे में जो पोस्ट कर रहा हूं, वह यह है कि यदि फुटवर्क किया गया था, तो क्या विलय के लिए पुल अनुरोध पर भी विचार किया जाएगा?

मैं इस धागे में जो पोस्ट कर रहा हूं, वह यह है कि यदि फुटवर्क किया गया था, तो क्या विलय के लिए पुल अनुरोध पर भी विचार किया जाएगा?

इस पर विचार किया जाएगा, लेकिन इसे SCons पर फायदेमंद साबित करना होगा।

एक बार जब आप सीएमके को सिर्फ एक और निर्माण प्रणाली मानते हैं और वास्तविक मानक नहीं, तो आप बहुत सारे विकल्पों के साथ समाप्त हो जाते हैं। स्कैन्स पर मेसन क्यों? या बेज़ल/हिरन भी अच्छे उपकरण हैं? लेकिन सीएमके के पक्ष में मेरे पास सबसे बड़ा तर्क उस पारिस्थितिकी तंत्र का समर्थन करने के लिए बनाया गया टूलिंग है। क्लैंग संकलन डेटाबेस, कई ऑपरेटिंग सिस्टम के लिए पैकेजिंग के लिए समर्थन, आदि। मैंने जो एकमात्र वैध डाउनसाइड सुना है वह खराब सिंटैक्स और डॉक्स है, लेकिन यह वास्तव में मेरे लिए इस पर अपनी स्थिति बदलने के लिए पर्याप्त मजबूत नहीं है।

स्कैन्स पर मेसन क्यों?

मेसन निंजा फाइलें बनाता है, जो वृद्धिशील विकास के लिए बहुत तेज है। इसके अतिरिक्त, विंडोज़ पर, आपको किसी भी प्रकार के विजुअल स्टूडियो पथ में हेरफेर करने की आवश्यकता नहीं

या बेज़ल/हिरन भी अच्छे उपकरण हैं?

यह देखते हुए कि बेज़ेल और हिरन दोनों जावा में लिखे गए हैं (एक निर्भरता गोडोट केवल तभी है जब आप एंड्रॉइड को लक्षित करेंगे, और तब भी कोई तकनीकी रूप से केवल एनडीके का उपयोग कर सकता है), मैं तर्क दूंगा कि वे सभी के लिए प्राथमिक निर्भरता के रूप में सही हैं उपयोगकर्ता। पायथन पहले से ही निर्भरता सूची में है, और आप एक त्वरित pip install 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)

मुझे लगता है कि मुझे ध्यान देना चाहिए, वैसे, सभी सी ++ बिल्ड सिस्टम में से, मेसन कम से

लेकिन इन सबसे ऊपर (और मुझे लगता है कि यह वास्तव में एक महत्वपूर्ण बात है, खासकर उन लोगों के लिए जो गोडोट का उपयोग gdnative के रूप में करते हैं), मेसन मूल रूप से प्रीकंपील्ड हेडर का समर्थन करता है। सीएमके नहीं करता है (और बिल्ड को हैक करने के लिए कोटायर का उपयोग करने से इसके मूल्य से अधिक समस्याएं हो सकती हैं)।

मैं आपको यह नहीं बता सकता कि यह gdnative उपयोगकर्ताओं के लिए निर्माण को कितना तेज़ कर सकता है, लेकिन यह gcc और msvc पर एक महत्वपूर्ण बढ़ावा होगा (कम से कम, msvc पर एक प्रदर्शन वृद्धि अपरिहार्य है)। गोडोट में पाए जाने वाले टेम्प्लेट कोड की बहुत कम मात्रा के लिए extern template के उपयोग में जोड़ें, और आप अच्छे निर्माण समय में सुधार देख सकते हैं, जो पुनरावृत्ति और वृद्धिशील बिल्ड के लिए महत्वपूर्ण हैं।

मेसन निंजा फाइलें बनाता है, जो वृद्धिशील विकास के लिए बहुत तेज है।

ध्यान दें कि सीएमके पारंपरिक मेकफाइल्स के बजाय निंजा बिल्ड फाइलें भी उत्पन्न कर सकता है; यह इसकी कमांड लाइन में -G Ninja पास करके किया जाता है। यह मैंने कोशिश की अधिकांश परियोजनाओं पर काफी अच्छी तरह से काम करता है और समग्र रूप से थोड़ा तेज़ है (साथ ही, यह डिफ़ॉल्ट रूप से सभी CPU थ्रेड का उपयोग करेगा)।

मेसन अभी भी कच्चे प्रदर्शन की तुलना में जीतता है जो मैंने देखा है, लेकिन यह निश्चित रूप से मेसन और सीएमके के प्रदर्शन के बीच के अंतर को बंद करने में मदद करता है।

हां, हालांकि, सीएमके स्वचालित रूप से आपके लिए निंजा स्थापित नहीं करता है, और यह डिफ़ॉल्ट जनरेटर नहीं है। मेरे अनुभव में, सीएमके का अधिकांश समय परियोजना को कॉन्फ़िगर करने में व्यतीत होता है, और जबकि सीएमके के हाल के संस्करणों ने प्रदर्शन में काफी सुधार किया है, सभी के पास नवीनतम सीएमके नहीं होगा।

ठीक है यह काफी गहन है! मुझे खुशी है कि आपके पास बिल्ड सिस्टम में आपके द्वारा मूल्यवान सुविधाओं के बारे में एक अच्छा विचार है। मुझे अभी भी लगता है कि सी ++ दुनिया में एक मानक निर्माण प्रणाली होनी चाहिए जिस पर परियोजनाएं भरोसा कर सकें। मेरी इच्छा है कि मेसन अपनी चीज के विपरीत सीएमके ट्रांसपिलर थे।

मुझे अभी भी लगता है कि सी ++ दुनिया में एक मानक निर्माण प्रणाली होनी चाहिए जिस पर परियोजनाएं भरोसा कर सकें।

मेरा विश्वास करो, यह मुझसे ज्यादा कोई नहीं चाहता। मैं एक बिल्ड सिस्टम ट्रैश गॉब्लिन की तरह बन गया हूं और यहां तक ​​​​कि उन पर CppCon में एक बात भी दी है। मैं दुर्भाग्य से (या सौभाग्य से?) निर्माण प्रणालियों के बारे में बहुत परवाह करता हूं, लगभग जुनून के बिंदु तक। :)

मैं बस यह कहना चाहता हूं, लेकिन हर बार जब मैंने विंडोज़ पर गोडोट का लंबा निर्माण किया है, तो मैंने देखा है कि पायथन लगातार मेरे सीपीयू का 15% हिस्सा लेता है। मुझे संदेह है कि यह शुरू करने के लिए केवल धीमा है।

मेसन से निर्मित एक छोटा प्रोटोटाइप गोडोट इंजन कौन बनाएगा? मैं बेज़ेल के लिए एक छोटा परीक्षण बनाने की बात पर कभी नहीं पहुंचा।

सभी विकल्पों को अक्षम करने के साथ परीक्षण करने के लिए केवल 2d गोडोट का निर्माण पर्याप्त होना चाहिए।

मेरे सामने पहली बाधा core/make_binders.py थी। यह ऑटोजेनरेटेड कोड है जो गोडोट उपयोग करता है।

मैंने बिल्ड सिस्टम Bazel में एक प्रारंभिक प्रोटोटाइप बनाया लेकिन मैं किसी अन्य मुद्दे पर सेटअप पर चर्चा करूंगा। https://github.com/godotengine/godot/issues/18518

सप्ताह भर के लिए समय नहीं है, लेकिन अन्य लोग Bazel BUILD पर विस्तार कर सकते हैं।

लॉल बाजेल कैसे शामिल हुआ?

चूंकि एक अलग बिल्ड सिस्टम पर स्विच करने का एक बार मौका हो सकता है, क्या हमें सर्वोत्तम संभव विकल्पों की तलाश नहीं करनी चाहिए? मैं एक के लिए एक केक बनाम बाजेल बनाम स्कैन्स तुलना चार्ट देखने में दिलचस्पी ले सकता हूं, हालांकि मुझे यह स्वीकार करना होगा कि मेरे पास उन परीक्षणों के लिए फुटवर्क करने के लिए केक के साथ शून्य अनुभव है।

@rraallvv क्या आपका मतलब केक या

@isaachier मेरा बुरा, मैं www.cakebuild.net के बारे में बात कर रहा था, मुझे और अधिक विशिष्ट होना चाहिए था, इसके बारे में खेद है।

क्या यह सिर्फ सी # के लिए नहीं है?

@isaachier मैं वास्तव में नहीं जानता, इस बार मैं मान रहा था कि केक उसमें सक्षम था, जैसे स्कैन्स को पायथन में लिखा जा रहा था और सी ++ के लिए समर्थन था। फिर भी, मैंने अभी उनकी गटर चैट में पूछा, मैं यहां जवाब दोबारा पोस्ट करूंगा।

रिकॉर्ड के लिए @rraallvv मुझे लगता है कि प्रमुख बिल्ड सिस्टम की साइड-बाय-साइड तुलना का विचार एक अच्छा विचार है। यहाँ मैंने जो ऑनलाइन पाया है वह मुझे लगता है कि काफी निष्पक्ष है (बिल्ड सिस्टम डेवलपर्स द्वारा नहीं लिखा गया है): https://carlosvin.github.io/posts/choosing- आधुनिक-cpp-stack , https://stackoverflow.com/a/12022652/1930331।

मेरी व्यक्तिगत राय:

• सीएमके : बहुत बदसूरत भाषा, लेकिन सर्वव्यापी और व्यावहारिक रूप से उद्योग मानक।
• स्कैन : धीमा, पुराना और आईडीके स्थिति। पायथन का उपयोग करता है।
• मेसन : नया, कूल, पायथन-आधारित बिल्ड सिस्टम जो अविश्वसनीय रूप से धीमा नहीं है। मुख्य नुकसान प्रक्षेपवक्र है। स्पष्ट नहीं है कि यह सप्ताह निर्माण प्रणाली का सिर्फ एक और स्वाद होगा।
• Autotools : प्राचीन, कोई टूलींग समर्थन नहीं (यानी क्लैंग स्वत: पूर्ण समर्थन या स्थिर विश्लेषण के लिए संकलन डेटाबेस)। कोई विंडोज़ समर्थन नहीं। हर कीमत पर बचें।
• bazel : एक Google पैकेज-मैनेजर/बिल्ड-सिस्टम एक में लुढ़क गया। हंटर जैसे प्लगइन के साथ सीएमके पर ज्यादा कुछ नहीं जोड़ता है। साथ ही, Google सॉफ़्टवेयर में इस बात पर ध्यान केंद्रित करने की प्रवृत्ति होती है कि Google को क्या चाहिए, न कि बड़े पैमाने पर। लंबी अवधि के प्रक्षेपवक्र को नापने के लिए बहुत नया।

जब भी मुझे मौका मिलता है मैं सीएमके को आगे बढ़ाने की कोशिश करता हूं क्योंकि मुझे सी ++ के लिए एक वास्तविक मानक चाहिए और सीएमके के पास अभी सबसे बड़ा "बाजार-शेयर" है।

@isaachier उस जानकारी को साझा करने के लिए धन्यवाद, मैं सी # को यह सी ++ आरईपीएल का उपयोग एक बिल्ड सिस्टम के लिए किया जा सकता है यदि कोई अगले स्तर पर जाना चाहता है और उस बहस को समाप्त करना चाहता है जिस पर एक बेहतर, तेज, आदि है।

मुझे समझ नहीं आ रहा है। सी ++ शायद एक भयानक निर्माण भाषा होगी। आंतरिक बिल्ड सिस्टम कोर AFAIK के साथ धीमेपन का अधिक लेना-देना है, न कि उपयोग की जाने वाली स्क्रिप्टिंग भाषा के विवरण के साथ।

@isaachier मेरा अनुमान है कि

यह एक अच्छा विचार है लेकिन अधिकांश खातों द्वारा मेसन को धीमा नहीं माना जाता है, फिर भी यह पायथन में लिखा गया है।

मुझे संदेह है कि मेसन सप्ताह का एक स्वाद होगा क्योंकि गनोम परियोजना वर्तमान में मेसन के पक्ष में ऑटोटूल को छोड़ रही है।

इसके अतिरिक्त, स्कैन धीमा नहीं है क्योंकि यह पायथन में लिखा गया है, बल्कि इसलिए कि यह बिल्ड को निष्पादित भी करता है। यह एक प्रत्यक्ष निर्माण प्रणाली है, जैसे मेक या निंजा, लेकिन परिभाषाओं के लिए बड़ी मात्रा में एक्सएमएल का भी उपयोग करता है और इसके कोड की एक बड़ी मात्रा वास्तव में केवल एक्सएसएलटी रूपांतरण है।

दूसरी ओर, मेसन एक निर्भरता ट्री उत्पन्न करने के लिए अपनी बिल्ड स्क्रिप्ट को निष्पादित करता है, और फिर इसे एक निंजा फ़ाइल में डंप करता है। मेसन तेज है, क्योंकि निंजा तेज है। इसके अतिरिक्त, मेसन में सब कुछ एक स्ट्रिंग नहीं है, जैसे सीएमके में।

अंत में, मुझे ध्यान देना चाहिए, विकास निर्माण प्रणालियों में कई ऐसे हैं जहां आप सी ++ में स्क्रिप्ट करने में सक्षम होंगे (मैं वास्तव में उनमें से एक लिख रहा हूं)। हालांकि, गोडोट को एक बिल्ड सिस्टम में जाने के लिए कह रहा है जो अभी तक मौजूद नहीं है ( और इससे भी बदतर, कि मैं खुद लिख रहा हूं) थोड़ा अभिमानी है, मेरी इतनी विनम्र राय में नहीं;)

मैं भी दोहराना चाहता हूं, वर्तमान विकास कार्यप्रवाह के तहत अजगर एक आवश्यकता है। तो, भी, मेसन है। और यह मेसन को अजगर के pip टूल पर कॉल के रूप में सरल बनाता है।

मैं @reduz से पूरी तरह सहमत स्कैन को धीमा होने के लिए नहीं

जैसा कि @ स्लर्प्स-मैड-रिप्स ने कहा:

स्कैन धीमा है इसलिए नहीं कि यह अजगर में लिखा गया है, बल्कि इसलिए कि यह बिल्ड को भी निष्पादित करता है

आदमी का अपमान:

scons समानांतर में a -j विकल्प के माध्यम से कई लक्ष्यों के निर्माण का समर्थन करता है, जो इसके तर्क के रूप में, एक साथ कार्यों की संख्या को जन्म दे सकता है:
स्कैन्स -जे 4

मेरे पास 8c16t वाला CPU है, इसलिए "scons p=x11 -j 18" का उपयोग करना मेरे लिए बहुत तेज़ है।
यह "scons p=x11" को डिफ़ॉल्ट सेटिंग "-j 1" के रूप में उपयोग करने की तुलना में 10x तेज है।
क्या किसी के पास वर्ष 2018 में सिंगल कोर सीपीयू है?
अपने CPU को पूरी तरह से काम करने दें।
कृपया इसे एक कोशिश का मौका दीजिए।

हर किसी के पास ये बड़े सीपीयू नहीं होते हैं, लेकिन इससे भी महत्वपूर्ण बात यह है कि वृद्धिशील पुनर्संयोजन में मेसन (अच्छी तरह से, निंजा) बहुत तेज है। स्कैन, डिफ़ॉल्ट रूप से, यह देखने के लिए कि कोई फ़ाइल बदल गई है या नहीं, MD5 हैश योग करता है। गोडोट MD5-टाइमस्टैम्प सेटिंग का उपयोग करता है, जिसका अर्थ है कि यह केवल एक फ़ाइल हैश करेगा यदि टाइमस्टैम्प बदल गया है। यह अभी भी हास्यास्पद है।

मुझे लगता है कि जो बेहतर है उसे साबित करने का सबसे अच्छा तरीका एक नया लिखना और देखना है :)

कई लोगों के लिए स्कैन तेज़ नहीं है, विशेष रूप से विंडोज़ उपयोगकर्ता जो उपरोक्त किसी भी चीज़ के साथ समस्या में चल रहे हैं -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 फिर बिल्कुल अलग विषय, स्कैन नहीं। मेरा मतलब सिर्फ मेक बनाम निंजा पागल अंतर नहीं है।

थोड़ा अपडेट: मैं मेसन में जाने की कोशिश करना छोड़ रहा हूं। यह टुकड़ा-टुकड़ा हो गया है और जबकि बिल्ड फाइलें पढ़ने में थोड़ी आसान हैं, वर्तमान सिस्टम के साथ अद्यतित रहना वह जगह है जहां मेरा अधिकांश (अब दुर्लभ और कम आपूर्ति में) खाली समय खर्च किया जाता है, बजाय स्कैन को मेसन में ले जाने के।

अभी, बहुत सारे कोड और संचालन सीधे स्कैन स्क्रिप्ट में रखे जाते हैं और इससे किसी अन्य बिल्ड सिस्टम में जाना अधिक कठिन हो जाता है। अगर कुछ भी मैं तर्क दूंगा कि मौजूदा पायथन लिपियों को डिकूप करने में समय बिताया जाना चाहिए जो स्कैन से कोड उत्पन्न करते हैं, क्योंकि यह मेसन, सेमेक, या यहां तक ​​​​कि बेज़ेल जैसे किसी अन्य बिल्ड सिस्टम में बहुत आसान हो जाएगा।

अच्छी बात यह है कि सभी कोड पीढ़ी को बाहर निकालने के लिए एक पैच को विलय कर दिया गया था। https://github.com/godotengine/godot/pull/17595 हार मत

स्कैन परियोजना सह-प्रबंधक यहाँ। एक युगल नोट:
1 - स्कैन सक्रिय विकास के अधीन है और हमारे जीथब में प्रवास के बाद से हम पुल अनुरोधों की बढ़ी हुई दर देख रहे हैं।
2 - हमने स्कैन के कुछ विशिष्ट भागों की पहचान की है जो लगभग 50% शून्य वृद्धिशील निर्माण समय के लिए जिम्मेदार हैं और सक्रिय रूप से इसे संबोधित करने के लिए काम कर रहे हैं। (पदार्थ कार्यक्षमता)
3 - हमने स्कैन 3.0 . के साथ पायथन 3.5+ (साथ ही 2.7.x) का समर्थन करना शुरू कर दिया है
4 - मेरा सुझाव है कि एन अलग-अलग बिल्ड सिस्टम को पोर्ट करने के प्रयास के बजाय, स्कैन को बेहतर बनाने में मदद करने के लिए कुछ समय देना डेवलपर समय का अधिक प्रभावी उपयोग हो सकता है
5 - हमने प्रदर्शन में सुधार के लिए कुछ कम लटके फलों की रूपरेखा के माध्यम से पहचान की और उन्हें संबोधित किया जो 3.0.0 और 3.0.1 में जारी किया गया था। यदि आप पुराने संस्करण का उपयोग कर रहे हैं तो शून्य वृद्धिशील निर्माण 5-15% धीमा हो सकता है। (पायथन 2.7.x मानते हुए)

हमेशा की तरह SCons प्रोजेक्ट उन परियोजनाओं की मदद करने के लिए तैयार और इच्छुक है जो SCons का उपयोग उन मुद्दों के साथ करते हैं जिनमें वे चलते हैं।

स्कैन और गोडोट के लिए कुछ "आंकड़े"।

मैंने एक Q6600 का उपयोग किया (और अभी भी करता हूं) जो 2008 से 4 कोर सीपीयू है या तो 2.4GHZ (और प्रति चक्र गणना के कम निर्देश) के साथ प्रोसेसर की तुलना में हम आज (i7s) का उपयोग कर "सभी" हैं।

Q6600 पर, एक निर्मित में 3 से 5 मिनट (या अधिक, लेकिन सटीक संख्या महत्वपूर्ण नहीं है) के बीच लिया गया था, जिसमें से ~ 35-40 सेकंड स्कैन द्वारा निर्भरता और सामान के पेड़ को पार्स करने में खर्च किए गए थे (तैयारी का काम) ... इसलिए, 80% समय cl.exe (MSVC कंपाइलर) प्रक्रिया को बार-बार चलाने में व्यतीत होता है।

इसलिए, प्रदर्शन और अनुकूलन के अनुसार, जब तक कि स्कैन्स (पायथन वास्तव में, स्कैन नहीं) में एक भयानक प्रक्रिया कॉलिंग सिस्टम है जो इससे अधिक समय ले रहा है या कुछ अन्य उपकरण प्रति प्रक्रिया एक फ़ाइल को संकलित नहीं कर रहे हैं (जैसे स्कैन वर्तमान में है) और 1 प्रति एक फ़ाइल ओवरहेड प्रक्रिया महत्वपूर्ण है (मैं cl.exe अनुपालन आंतरिक और स्टार्टअप ओवरहेड्स पर एक विशेषज्ञ नहीं हूं), एकमात्र प्रदर्शन अनुकूलन एक तेज निर्माण प्रणाली का उत्पादन शायद निर्भरता वृक्ष चरण के निर्माण में है, और जटिलता के लिए अन्य प्रीवर्क .

इसलिए, हम 5 मिनट के निर्माण में से 35-40 सेकंड का अनुकूलन कर रहे हैं (i7 के अब हम शायद 3 मिनट के मल्टी कोर बिल्ड में से 20 सेकंड के सिंगल कोर सेटअप चरण को अनुकूलित कर रहे हैं)।

तो, संक्षेप में, अगर मुझे सही से याद है, तो 3 से 5 मिनट वास्तव में 4 कोर मल्टीकोर बिल्ड है, जबकि एक सिंगल कोर बिल्ड में लगभग 10 लगते हैं? मुझे अपने परीक्षण फिर से चलाने की जरूरत है ...

तो, स्कैन को "अनुकूलित" करने का मतलब है कि बिल्ड के पहले 35 सेकंड के कमोबेश ऑप्टिमाइज़ करना शुरू हो जाता है ...

जहां तक ​​"ऑप्टिमाइज़ेशन" का संबंध है, जब स्कैन बनाम अन्य तेज़ बिल्ड सिस्टम की बात आती है ... प्रक्रिया ओवरहेड महत्वपूर्ण है (मुझे डर है कि एचडीडी हमेशा वास्तविक आईओ बाधा होगी (और सीपीयू नहीं), जो एसएसडी के बिना परिहार्य/शमन योग्य नहीं है)

उपरोक्त सभी अनुच्छेद "पूर्ण निर्माण" पर विचार करते हैं। उस ने कहा, स्कैन "धोखा देती है" यदि सब कुछ पहले से ही बनाया गया है और इसकी भारी हाथ स्थिरता जांच पास करता है, इसलिए यदि आप एक फ़ाइल बदलते हैं तो यह वास्तव में "एकल फ़ाइल" संकलित करेगा और फिर सबकुछ वापस लिंक करेगा, कुछ हद तक "पूर्ण निर्माण" बना देगा एक वृद्धिशील निर्माण के)। हालाँकि इसके लिए उन 35-40 सेकंड की पूर्ण निर्भरता ट्री प्रीकंप्यूटेशन की आवश्यकता होती है ...

तो, मेरे पुराने कंप्यूटर पर "वृद्धिशील बिल्ड" लगभग 45 सेकंड है, और मैंने सोचा था कि जब मैं 2 साल पहले एक नोब था कि यह सीपीयू बाध्य होगा, लेकिन वास्तव में, यह आईओ बाध्य हो सकता है (एचडीडी पर कई हजार फाइलों की जांच कर रहा है) ) एक पूर्ण निर्भरता स्वीप/पेड़ पुनर्निर्माण के लिए ... इसलिए, यदि यह आईओ बाध्य है, तो कोई भी "तेज़ buidlsystem" इसे हल करने वाला नहीं है ...

2 साल पहले से मेरा हैकिश विचार स्कैन के लिए एक फाइल सिस्टम "वॉचर" संलग्न करने का प्रयास करना था, स्कैन को एक ही बदली हुई फ़ाइल (और यह निर्भरता, यह स्वचालित है) को चलाने और पुन: संकलित करने के लिए है, और उसके बाद बस इसे सब कुछ फिर से लिंक करें ... हालाँकि मुझे आज एहसास हुआ कि लिंकिंग अभी भी एक पूर्ण निर्भरता स्वीप चलाएगा ... उस ने कहा, निर्भरता ट्री स्वीप/पुनर्निर्माण को एक विकल्प के साथ मारा जा सकता है और फिर स्कैन इसके कैश्ड डीप ट्री का उपयोग करेंगे ... जो लगभग 15-20 बचाता है 35 सेकंड के प्रीकंप्यूटेशन चरण के सेकंड (पहले 15 सेकंड अपरिहार्य लगते हैं) हालांकि यह हमेशा "परफेक्ट" बिल्ड की गारंटी नहीं दे सकता है जैसे कि स्कैन करता है (हालांकि यह देव में वृद्धिशील बिल्ड के लिए महत्वपूर्ण नहीं हो सकता है ... यदि आप तय करते हैं कि गति है एक योग्य ट्रेडऑफ़)।

अब मेरे पास पर्याप्त ज्ञान है कि मैं शायद इसे npm और npm घड़ी के माध्यम से हैक कर सकता हूं ... और या अन्य सिस्टम जिससे मैं वर्तमान में परिचित नहीं हूं ... लेकिन यह बाद के लिए है, और जब मेरे पास समय है (वर्तमान में नहीं)।

यह थोड़ा लंबा हो रहा है इसलिए मैं इसे यहाँ समाप्त कर रहा हूँ, लेकिन इन पैराग्राफों का उद्देश्य आपको किसी को हतोत्साहित करने के लिए कुछ "सांख्यिकीय" जानकारी देना था (यदि आप बिल्ड सिस्टम पर काम करना पसंद करते हैं तो आगे बढ़ें), जैसे मुझे खुद पसंद आया गोडोट के स्कैन में कुछ सामान ठीक करना। मुझे आशा है कि यहां आप लोगों के लिए कुछ जानकारी उपयोगी थी।

यदि आप मेरे आँकड़ों को दोहराना/फिर से करना चाहते हैं, तो बस स्कैन दस्तावेज़ों के माध्यम से ब्राउज़ करें जब तक कि आप सांख्यिकीय जानकारी (टाइमर सामग्री) चालू न करें और/या निर्भरता पुनर्वितरण को बंद करने का कोई तरीका ढूंढें ("प्रीकंप्यूटेशन" के पहले 20 से 30-35 सेकंड )...

या थोड़ा कम मैनुअल समाधान के लिए, टाइमर डिबगिंग जानकारी पहले से मौजूद होनी चाहिए (संपादित करें: यह संभावना नहीं है, किसी ने ऐसा किया है जो बनाम प्रोजेक्ट पीढ़ी के लिए एक मीठे अपडेट की तरह दिखता है, यह पैराग्राफ पुरानी जानकारी हो सकती है) द्वारा उत्पन्न स्वचालित वीएस परियोजना में स्कैन (स्कोनस्ट्रक्ट फ़ाइल के अंत में)... आप गोडोट वेबसाइट पर "विंडोज संकलन ट्यूटोरियल" में वीएस प्रोजेक्ट कैसे उत्पन्न करें, इस बारे में जानकारी प्राप्त कर सकते हैं। फिर आप वीएस से स्कैन चला सकते हैं, मेरा मानना ​​​​है कि जेनरेट की गई परियोजना को अभी भी काम करना चाहिए, हालांकि मैंने इसे गोडोट 3 में परीक्षण नहीं किया है ... यह एक विकल्प है, लेकिन एक> log.txt के लिए स्कैन करना भी एक और विकल्प है (आदि) ...

यहाँ उम्मीद है कि किसी को यह जानकारी मददगार लगी।

@Greefchief बस चीजों को थोड़ा सा साफ़ करने के लिए, मुझे लगता है कि हम पूर्ण-निर्माण समय को अनुकूलित करने की कोशिश नहीं कर रहे हैं, क्योंकि वैसे भी कंपाइलर समय का प्रभुत्व है। इसके बजाय, हम वृद्धिशील बिल्ड को ऑप्टिमाइज़ करना चाहते हैं जहाँ केवल एक स्रोत फ़ाइल बदली जाती है।

वास्तव में "शून्य वृद्धिशील निर्माण" (वास्तव में कुछ भी पुनर्निर्माण करने की आवश्यकता नहीं है, लेकिन स्कैन को अभी भी यह सुनिश्चित करने के लिए पूरे निर्भरता पेड़ को संसाधित करने की आवश्यकता होगी) वह मामला है जिस पर हम काम कर रहे हैं।

कुछ प्रोफाइलिंग ने कमांड लाइनों को संसाधित करने में कुछ अक्षमताओं की ओर इशारा किया है (जो यह सुनिश्चित करने के लिए प्रत्येक लक्ष्य के लिए किया जाना है कि वे नहीं बदले हैं) की पहचान की गई है। इसका बड़ा हिस्सा Subst() तर्क है। यह कुछ मुश्किल कोड है और इस प्रकार अब तक एक सरल और सुरक्षित तरीके से लागू किया गया है, लेकिन भयानक तरीके से नहीं।

समय का एक और हॉट स्पॉट स्कैन्साइन फाइलों का पढ़ना और लिखना है, जो वर्तमान में सीपिकल के साथ कार्यान्वित किया जाता है और हमेशा पूरी तरह से पढ़ा और लिखा जाता है। हमारे पास कुछ विचार हैं कि कैसे या तो गति और/या अधिक वृद्धिशील करें। वैसे भी सुधार के लिए भविष्य की रिलीज़ देखें।

एक तरफ ध्यान दें, आप यह देखने के लिए MSVC_BATCH आज़मा सकते हैं कि क्या इससे आपकी विंडोज़ की गति तेज होती है:

एमएसवीसी_बैच
जब किसी वास्तविक मान पर सेट किया जाता है, तो निर्दिष्ट करता है कि Microsoft Visual C/C++ कंपाइलर को कॉल करते समय स्कैन को ऑब्जेक्ट फ़ाइलों का बैच संकलन करना चाहिए। एक ही स्रोत निर्देशिका से स्रोत फ़ाइलों के सभी संकलन जो एक ही आउटपुट निर्देशिका में लक्ष्य फ़ाइलें उत्पन्न करते हैं और एक ही निर्माण वातावरण का उपयोग करके स्कैन में कॉन्फ़िगर किए गए थे, संकलक को एक ही कॉल में बनाए जाएंगे। केवल स्रोत फ़ाइलें जो उनकी ऑब्जेक्ट फ़ाइलों के निर्माण के बाद से बदल गई हैं, प्रत्येक कंपाइलर आमंत्रण ($CHANGED_SOURCES निर्माण चर के माध्यम से) को पास की जाएंगी। कोई भी संकलन जहां ऑब्जेक्ट (लक्ष्य) फ़ाइल का आधार नाम (माइनस द .obj) स्रोत फ़ाइल के आधार नाम से मेल नहीं खाता है, अलग से संकलित किया जाएगा।

@ बोजिदार-बीजी हाँ, हाँ, मैं वास्तव में वृद्धिशील बिल्ड के बारे में भी बात कर रहा था, टिप के लिए धन्यवाद: डी

@bdbaddog हाय बैडॉग, आपकी जानकारी के लिए, मैंने आपकी टिप्पणी देखने से पहले वास्तव में मेरी यह बड़ी टिप्पणी लिखी थी, इसलिए, यह वास्तव में आपकी टिप्पणी में कुछ भी विशेष रूप से संदर्भित नहीं करता है ... लेकिन आपने कुछ का उल्लेख किया है " चिंताएँ" मेरे पास (वास्तव में अन्य लोगों के लिए जानकारी) थी, जबकि हम दोनों एक ही समय में अपनी टिप्पणी लिख रहे थे ...

और मैं आपको इसमें पिंग नहीं करना चाहता था क्योंकि मैं आपका समय "बर्बाद" नहीं करना चाहता था: डी, ​​लेकिन मुझे लगता है कि अगर मैं भविष्य में गोडोट बिल्ड/स्कैन पर कुछ और समय बिताऊंगा (मैं योजना बना रहा हूं, मैं मैं अभी बहुत व्यस्त हूँ))

यहां आपके इनपुट के लिए धन्यवाद!

@bdbaddog BD, चूंकि आप सहायता प्रदान कर रहे हैं, अगर मैं यहां पूछ सकता हूं:

अगर मैं फाइल सिस्टम (godot's source) में npm घड़ी संलग्न करता हूं और जानता हूं कि कौन सी सटीक फाइल बदली गई है, तो क्या इससे मुझे स्कैन के साथ कोई लाभ मिलेगा?

अब मैं npm घड़ी के माध्यम से स्कैन चला सकता हूं और फ़ाइल को उस पर धकेल सकता हूं ...

scons [godot options] the/file/that/was/changed.

यह स्पष्ट रूप से उस फ़ाइल को पुन: संकलित करेगा, शायद गोडोट के पूरे डीपी पेड़ से परहेज करेगा? सही? तो अब डीप ट्री ट्रैवर्सल में 20 सेकंड नहीं लगेंगे, लेकिन 1 प्रोब से कम, लेकिन मुझे 1 अपडेटेड .obj फ़ाइल मिलती है (या अधिक, आप जो बदलते हैं उस पर निर्भर करता है)। यह वास्तव में उस एक फ़ाइल के लिए पूरे गोडोट डीपी पेड़ से नहीं जायेगा? मुझे इस उदाहरण में कम डीपी ट्री ट्रैवर्सल में एक फायदा है (और संभवतः प्रीकंप्यूट चरण में अन्य फायदे जो कि डीपी ट्री कैश के पुन: उपयोग के माध्यम से प्राप्त नहीं किए जा सकते हैं, जैसे कि कम फाइलों के माध्यम से जाने के लिए?)?

अब, अगर मेरे पास एक फायदा है, और अगर मैं सब कुछ फिर से जोड़ना चाहता हूं, तो क्या मुझे "सरल" लिंकिंग चरण के लिए एक पूर्ण पेड़ ट्रैवर्सल की आवश्यकता होगी?

मैं समझता हूं कि यह उपयोगकेस वर्तमान में स्कैन द्वारा समर्थित नहीं हो सकता है (बस सब कुछ फिर से लिंक करें), लेकिन मैं व्यावहारिक और सैद्धांतिक दोनों दृष्टिकोण से पूछ रहा हूं? मुझे एहसास है कि कैश्ड डीप पेड़ का पुन: उपयोग किया जा सकता है कि "डिप पेड़ न करें" विकल्प (मैं इसे भूल गया, यह दो साल हो गया है), और यह कुछ उपयोगकेस के लिए काम करेगा, और वह उपयोगकेस कोई नई फाइल नहीं जोड़ा गया है, सही ? (एनपीएम घड़ी मुझे नई फाइल जोड़ने के लिए सतर्क कर सकती है और अगर मैं इसका पता लगाता हूं तो मैं एक पूर्ण डीप पेड़ रीफ्रेश कर सकता हूं ... उपयोगकर्ता द्वारा npm वॉच जैसे प्रोग्राम में मैन्युअल रूप से किए गए "डिपेंडेंसी कैश का उपयोग करें" विकल्प में टाइप करना ... फ़ाइल, स्कैन के काम करने के लिए बहुत अधिक समय दे रही है)

क्या मेरे विचार में कुछ ऐसा है जो अनुकूलन (व्यावहारिक रूप से और सैद्धांतिक रूप से) के रूप में काम नहीं करेगा, और क्या आपके पास अन्य सुझाव हैं (यदि एनपीएम घड़ी जैसी कोई चीज सामान की देखभाल कर सकती है, तो एक आदर्श निर्माण की गारंटी नहीं है, यह भी ठीक है )? क्या आप कृपया सलाह दे सकते हैं? शुक्रिया!

संक्षेप में, उपयोगकेस इस के समान है:

1) गोडोट की स्रोत निर्देशिका पर एनपीएम घड़ी की तरह एक फाइलवॉचर चलाएं
2) उपयोगकर्ता एक पुरानी फ़ाइल को सहेजता/संशोधित करता है
3) उस फ़ाइल के लिए npm द्वारा तुरंत स्कैन चलाया जाता है।
4) यदि संकलन सफल होता है, तो npm स्कैन को लिंकर चलाने और निष्पादन योग्य को लिंक करने का निर्देश देता है।

४.१) यदि डीप ट्री को कैश किया जाता है (एक पूर्ण बिल्ड पहले से ही चल रहा था), npm लिंकर को इस बिंदु पर डीपी ट्री के कैश्ड संस्करण के साथ लिंक करने का निर्देश दे सकता है
4.1) यदि कोई कैश्ड डेप ट्री नहीं पाया जाता है, तो npm वॉच एक पूर्ण गोडोट बिल्ड चलाती है
4.2) यदि कैश अमान्यता का पता चला था, जैसे एक नई फ़ाइल जोड़ना, एक पूर्ण डीपी ट्री ट्रैवर्सल निष्पादित करें (एनपीएम स्कैन के साथ "कैश्ड डीप ट्री का उपयोग करें" विकल्प का उपयोग नहीं करेगा)।

मुझे आशा है कि यह मेरे विचार को समझने में थोड़ा आसान बनाता है, कृपया मुझे बताएं कि इस समय इसमें क्या गलत है; डी

पीएस मेरा मानना ​​​​है कि यह वह आदेश है जो 35 शून्य वृद्धिशील बिल्ड में से 15 सेकंड से दूर है, इसके "स्पष्ट" परिणाम हैं ... मैं मूल रूप से यहां वर्णित चीज़ों को स्वचालित करना चाहता हूं (अधिक या कम, + स्कैन को यह जानने दें कि कौन सी सटीक फ़ाइल है संशोधित किया गया था अगर यह किसी भी तरह से मदद करता है (या यह इसकी मदद कर सकता है)):

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

तो यहाँ कुछ चीज़ें (किसी विशेष क्रम में नहीं, लेकिन मैं संख्याओं का उपयोग कर रहा हूँ क्योंकि yolo

1) वृद्धिशील नल बिल्ड मूल रूप से किसी भी उपकरण के तहत कुछ भी नहीं है जो निंजा फाइलें उत्पन्न करता है। क्रोम में, AFAIK, 2 सेकंड से कम अशक्त वृद्धिशील निर्माण है। यह महत्वपूर्ण नोट है, क्योंकि npm watch तहत 35 सेकंड की गिरावट 15 तक मेसन या सेमेक आधारित निंजा बिल्ड की तुलना में अभी भी बहुत बड़ी है। निंजा भी वही काम करता है जो स्कैन करता है कि वह उस स्थिति में पुनर्निर्माण करता है जब कमांड लाइन बदलती है (बेशक, ऐसा नहीं करता है)

2) सीएमके ने हाल ही में ग्लोब सिस्टम के तर्क के रूप में CONFIGURE_DEPENDS का उपयोग करने की क्षमता को लागू किया है। इसके खिलाफ हमेशा अनुशंसा की गई है क्योंकि xcodebuild और msbuild जैसे टूल ऐतिहासिक रूप से (और वर्तमान में) समर्थित निर्देशिका परिवर्तन पहचान का समर्थन नहीं करते हैं। यह, afaik, एक चीज है जिस पर स्कोन्स सुधार कर सकता है, लेकिन मेरे पास इसे लागू करने के लिए परियोजना में गहराई से गोता लगाने के लिए न तो समय है और न ही धैर्य है। मूल रूप से, प्रत्येक OS एक निर्देशिका को अद्यतन करता है जब उसकी सामग्री बदल जाती है, चाहे वह एक अतिरिक्त फ़ाइल हो, संशोधित फ़ाइल हो, या हटाई गई फ़ाइल हो। वृद्धिशील परिवर्तन करते समय, कोई केवल यह जांच सकता है कि कौन सी निर्देशिका बदल गई है और केवल उन निर्देशिकाओं को फिर से कॉन्फ़िगर करने पर ही ग्लोब करें। यह किए गए कार्य को कम कर सकता है क्योंकि आप पूरे पेड़ को नहीं, बल्कि छोटे टुकड़ों को ग्लोब कर रहे हैं। छोटी परियोजनाओं के लिए यह ठीक है। इससे गोडोट को लाभ होगा या नहीं इसके लिए कुछ परीक्षण की आवश्यकता होगी और यह जांचने के लिए बहुत काम है कि क्या यह मदद भी करेगा।

3) हालांकि यह देखकर अच्छा लगता है कि स्कैन्स पर अधिक ध्यान दिया जा रहा है, मुझे व्यक्तिगत रूप से लगता है कि गोडोट के लिए बड़े पैमाने पर समुदाय के लिए अधिक उपयोग की जाने वाली बिल्ड सिस्टम में जाना बेहतर है। मैं स्कैन्स का उपयोग करने वाली किसी भी बड़ी परियोजना के बारे में सोच नहीं सकता। गनोम/जीटीके हाल ही में मेसन (सीएमके को छोड़कर) में स्थानांतरित हो गया है, केडीई काफी समय से सीएमके पर है। हालांकि यह वास्तविक सबूत है (और इस प्रकार एक बुनियादी पुष्टिकरण पूर्वाग्रह), मैं कई सी ++ डेवलपर्स के बारे में जानता हूं जो गोडोट को आजमाना चाहते हैं, लेकिन उन्हें फिर से स्कैन को छूना नहीं पड़ेगा। खराब अनुभवों को दूर करना और इस प्रकार डेवलपर्स के मुंह में छोड़े गए खट्टे स्वाद को दूर करना मुश्किल है, और मैं ईमानदारी से स्कैन्स प्रोजेक्ट को सर्वश्रेष्ठ की कामना करता हूं। लेकिन मुझे पता है कि सी ++ समुदाय बड़े पैमाने पर पहले से ही लंबे संकलन समय से नफरत करता है। आधुनिक दुनिया में लंबी वृद्धिशील नल बिल्ड (या 1 फ़ाइल की लंबी वृद्धिशील बिल्ड) एक बुरा सपना है।

मैं फिर से प्रयास करने का इरादा रखता हूं, लेकिन मैं इसके लिए सीएमके को लक्षित कर सकता हूं। सीएमके से मेसन में जाना बहुत आसान है धन्यवाद मेसन के पास एक रूपांतरण स्क्रिप्ट है जो बहुत काम कर सकती है। सीएमके नए FetchContent मॉड्यूल के साथ निर्भरता को संभालना थोड़ा आसान बना सकता है। हम देखेंगे कि यह कैसे काम करता है। मैं कहूंगा, मुझे खुशी है कि इन कोडजन लिपियों को अलग फाइलों में ले जाया गया। सीएमके का उपयोग करना अच्छा होगा यदि केवल इसलिए कि एक अलग सी ++ मानक पर जाना target_compile_features(<target> (PUBLIC|PRIVATE|INTERFACE) cxx_std_<number>) जितना आसान है

जाहिर है कि कोई भी बिल्ड सिस्टम से संबंधित सामान विवादास्पद होने वाला है, लेकिन कोशिश करने से चोट नहीं लग सकती।

काफी ईमानदार होने के लिए, (और यह कठोर के रूप में सामने आ सकता है) मुझे इसे सुधारने के लिए स्कैन्स प्रोजेक्ट में गहरी गोता लगाने की कोई इच्छा नहीं है। हो सकता है कि 2020 के बाद जब पायथन 2.7 आधिकारिक तौर पर वास्तव में मर चुका हो और परियोजना पायथन 3.5+ पर आगे बढ़ सकती है, केवल यह जांच या सुधार के लायक होगा, संभवतः async संचालन के साथ। हालाँकि, तब तक, मुझे इसे छूना नहीं पड़ेगा।

हो सकता है कि 2020 के बाद जब पायथन 2.7 आधिकारिक तौर पर वास्तव में मर चुका हो और परियोजना पायथन 3.5+ पर आगे बढ़ सकती है, केवल यह जांच या सुधार के लायक होगा

स्कैन्स 3 पायथन 3.5+ का समर्थन करता है: https://scons.org/tag/releases.html ।

मैं वास्तव में यह नहीं समझता कि कोई स्कैन्स को इतना नापसंद कैसे कर सकता है और कॉन्फ़िगरेशन गड़बड़ जो कि सीएमके है, जहां आपकी खुद की बिल्ड सेटिंग्स को परिभाषित करना मुश्किल है यदि आप एक उपयोगकर्ता हैं, तो यह समझना मुश्किल है कि विकल्प और उनके प्रकार क्या हैं और क्या हैं आंतरिक परिभाषाएँ हैं, यह केवल मेरे लिए दर्द लेकर आया, और मुझे वास्तव में राहत मिली कि गोडोट ने इसका उपयोग नहीं किया।

किसी भी मामले में, अगर आपको लगता है कि यह एक बेहतर समाधान होने जा रहा है और कोशिश करें, तो मैं सीएमके पर अपना विचार बदल सकता हूं।

यदि आप एक उपयोगकर्ता हैं, तो अपनी स्वयं की बिल्ड सेटिंग्स को परिभाषित करना और भी कठिन है,

अगर ऐसा पूछा जाता है तो सीएमके का गलत इस्तेमाल किया जा रहा है। सभी टूलचेन सेटिंग्स टूलचेन फ़ाइल में होनी चाहिए और किसी भी प्रोजेक्ट विशिष्ट कॉन्फ़िगरेशन को झंडे (या गुई या कैश फ़ाइल या जो कुछ भी संपादित करें) के माध्यम से पारित किया जाता है। सब कुछ प्रलेखित और टाइप किया गया है, यहां तक ​​​​कि परियोजना लेखक भी अच्छी तरह से दस्तावेज कर सकते हैं और उनके उजागर कॉन्फ़िगरेशन को टाइप कर सकते हैं। आपको सीगोल्ड और आधुनिक सीएमके मानकों को पढ़ना चाहिए।

@ कोई भी इनकार नहीं करता है कि

@ OvermindDL1 को सीगोल्ड पढ़ने का सुझाव पसंद आया।

अगर ऐसा पूछा जाता है तो सीएमके का गलत इस्तेमाल किया जा रहा है

खैर, मुझे लगता है कि सभी कार्यक्रमों का सामना करना पड़ा जहां यह गलत हो रहा था।

ईमानदार होने के लिए, मुझे -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (वास्तव में? on ?) के माध्यम से झंडे बदलने से नफरत है। कैश फ़ाइल O_o को संपादित करने के विचार का उल्लेख नहीं करना। या, अगर मैं एक ध्वज बदलना चाहता हूं, तो मुझे मूल रूप से बिल्ड फ़ोल्डर को हटाना होगा और स्क्रैच से शुरू करना होगा (क्योंकि, आप जानते हैं, कैश अलग है!) ... वृद्धिशील बिल्ड के लिए बहुत कुछ ...

संपादित करें: इसके अलावा, एक चीज जो मुझे वास्तव में स्कैन्स के बारे में पसंद आई (कम से कम गोडोट में, और यह निश्चित रूप से अन्य बिल्ड सिस्टम के साथ संभव हो सकता है), यह है कि मैंने वास्तव में कोई मानक या दस्तावेज़ नहीं पढ़ा है, मैं सिर्फ scons -h चलाता हूं

गिटहब पर मैंने जो 95% बिल्ड फाइलें देखी हैं, वे गलत हैं। लोग सिस्टम बनाने के बारे में आलसी हो जाते हैं और एक साथ कुछ इकट्ठा करने के लिए कार्गो पंथ प्रथाओं का पालन करते हैं।

@isaachier , एक मीट्रिक के रूप में, क्या आप एक खराब और अच्छी सीएमके फ़ाइल के 2 उदाहरण प्रदान कर सकते हैं? आप इस पर कैसे विचार करेंगे: https://github.com/ARMmbed/mbedtls/blob/Development/CMakeLists.txt ?

मैंने जो देखा है उससे बेहतर। फिर भी, यदि आप सीएमके>= 3.0 का उपयोग नहीं कर रहे हैं, तो आपका अनुभव आधुनिक सीएमके के साथ नहीं है।

खैर, मुझे लगता है कि सभी कार्यक्रमों का सामना करना पड़ा जहां यह गलत हो रहा था।

मैं आजकल इसे अच्छी तरह से करते हुए देखता हूँ।

ईमानदार होने के लिए, मुझे -DI_LOVE_CMAKE_AND_MAKE_DEFINES_LONG=on (वास्तव में? चालू?) के माध्यम से झंडे बदलने से नफरत है। कैश फ़ाइल O_o को संपादित करने के विचार का उल्लेख नहीं करना। या, अगर मैं एक ध्वज बदलना चाहता हूं, तो मुझे मूल रूप से बिल्ड फ़ोल्डर को हटाना होगा और स्क्रैच से शुरू करना होगा (क्योंकि, आप जानते हैं, कैश अलग है!) ... वृद्धिशील बिल्ड के लिए बहुत कुछ ...

आपको on का उपयोग करने की आवश्यकता नहीं है, आप true , 1 और कई अन्य चीजों का उपयोग कर सकते हैं। यह इसे बनाने के लिए है ताकि आप एक उपयुक्त बूलियन नाम चुन सकें जो ध्वज नाम के साथ अच्छी तरह से बहता हो।

और यदि आप विकल्प बदलते हैं तो आपको कभी भी बिल्ड फ़ोल्डर के पुनर्निर्माण की आवश्यकता नहीं होनी चाहिए, जब आवश्यक हो तो सेमेक पुनर्निर्माण में असाधारण रूप से अच्छा होता है।

फिर भी, C/C++ बिल्ड सिस्टम को छूने वाले प्रत्येक व्यक्ति को CGold के साथ-साथ CMake के आधिकारिक मैनुअल को पढ़ना चाहिए। सीएमके का सही उपयोग करना वास्तव में आसान है, यह अक्सर बहुत छोटा भी होता है। प्राचीन सीएमके 2 पद्धतियों का उपयोग नहीं किया जाना चाहिए। वास्तव में, कोई भी जो सीएमके 2.x संस्करण पर निर्भर करता है वह बिल्कुल गलत काम कर रहा है (लक्ष्य और टूलचेन का ठीक से उपयोग नहीं कर रहा है, विकल्प ठीक से सेट नहीं कर रहा है, आदि ... आदि ...)।

स्पष्टीकरण के लिए धन्यवाद, जबकि मुझे संदेह है, मैं यह देखने के लिए उत्सुक हूं कि यह गोडोट के लिए कैसे काम करेगा :)।

@ slurps-mad-rips सी ++ 11 मोड को सक्षम करने के लिए अनुमानित सीएमके उदाहरण कोड के साथ आपकी पोस्ट पूरी तरह से गैर-मानक सीएमके है, जिसमें कई कारणों से शामिल है, लेकिन इन तक सीमित नहीं है:

• अनएक्सपोज़्ड वैरिएबल सेट करना।
• टूलचैन तर्क गैर-टूलचेन फ़ाइल में सेट किए गए हैं।
• बिल्कुल नहीं कि आप 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)

और यह सुनिश्चित करेगा कि प्रयुक्त टूलचेन जानता है कि उसे उस मोड को सेट करने की आवश्यकता है (और यदि आप एक कंपाइलर का उपयोग कर रहे हैं जो इसका समर्थन नहीं करता है तो आप निर्दिष्ट कर सकते हैं कि विफलताओं को कैसे संभालना है)। बिल्ड फ़ाइल में विशेष कंपाइलर-विशिष्ट कमांड लाइन फ़्लैग मानना ​​​​अत्यंत खराब रूप है क्योंकि वे केवल टूलचेन फ़ाइलों में मौजूद होने चाहिए और तथ्य यह है कि पूर्व पोस्ट में दिखाया गया मेसन उदाहरण वास्तव में विशिष्ट तर्कों को निर्दिष्ट करता है अनिवार्य रूप से इसका मतलब है कि आप समर्थित कंपाइलर्स को हार्डकोड कर रहे हैं।

यह ध्यान में रखते हुए कि किसी भी टूलचेन के लिए एक पूर्व-निर्मित सीएमके टूलचेन फ़ाइल है जिसके बारे में आप सोच सकते हैं (विभिन्न किस्मों के एमएसवीसी के सभी मानकों, जीसीसी/क्लैंग, एंड्रॉइड, आईओएस, एमस्क्रिप्टन, आदि ... आदि ... सहित) आप पहिया का पुन: आविष्कार नहीं करना चाहिए। यदि उपयोगकर्ता जो गोडोट की तरह कुछ संकलित कर रहा है, अपने स्वयं के कस्टम कंपाइलर का उपयोग अद्वितीय कमांडलाइन तर्कों के साथ करना चाहता है (जैसे इंटेल के कंपाइलर या शायद कुछ समर्पित चिप या सिर्फ एक साधारण आरपीआई) तो बिल्ड स्क्रिप्ट को इसकी परवाह करने की आवश्यकता नहीं है या किसी भी बदलाव की आवश्यकता है (कोड निश्चित रूप से हो सकता है, लेकिन बेहतर रूप से यह कभी भी नहीं होना चाहिए क्योंकि सीएमके यह बता सकता है कि सभी परिभाषाओं के माध्यम से क्या समर्थित है) और उपयोगकर्ता निर्माण के लिए अपनी स्वयं की कस्टम टूलचेन फ़ाइल की आपूर्ति कर सकता है।

संपादित करें: और व्यापक समर्थन को कभी छूट न दें। मुझे मेसन के बारे में कुछ भी नहीं मिल रहा है जो केडेवलप के लिए प्रोजेक्ट फाइल जेनरेट करने में सक्षम है (आईडीई मैं उपयोग करता हूं, जो दिलचस्प रूप से सीएमके का निर्माण प्रारूप के रूप में उपयोग करता है, मैं कभी-कभी काम पर क्लियन का उपयोग करता हूं, यह सीएमके का भी उपयोग करता है), जहां लगभग हर आईडीई आउट ( यहां तक ​​कि विजुअल स्टूडियो!) अब मूल रूप से सीएमके परियोजनाओं को खोल सकता है (यदि आप चाहें तो सीएमके अधिकांश आईडीई के लिए सीधे परियोजनाएं उत्पन्न करने में सक्षम होने के अतिरिक्त)।

@OvermindDL1

यह पूरी तरह से गैर-मानक सीएमके नहीं है। कोड नमूना सीएमके 3.0 को लक्षित करता है, एक ऐसा संस्करण जिसमें CXX_STANDARD मौजूद नहीं है। आप यहां से आसानी से देख सकते हैं कि आप target_compile_features साथ cxx_std_ और मानक की संख्या का उपयोग करते हैं। मानक संस्करण सेट करने के लिए यह नया और आधुनिक सेमेक तरीका है। set_target_properties एक पुराना प्रति-लक्षित दृष्टिकोण है।
वास्तव में, सीएमके के दस्तावेज़ीकरण से लिया गया सटीक कोड है

target_compile_features(mylib PUBLIC cxx_std_11)

हालांकि, CXX_STANDARD क्लैंग के लिए libc++ समर्थन सेट नहीं करता है क्योंकि क्लैंग लिनक्स पर डिफ़ॉल्ट रूप से libstdc++ का उपयोग करता है जब तक कि कॉन्फ़िगर नहीं किया जाता है (और इसे अधिकांश लिनक्स वितरणों पर डिफ़ॉल्ट रूप से libc++ का उपयोग करने के लिए कभी भी कॉन्फ़िगर नहीं किया जाता है, क्योंकि इससे लिंकर त्रुटियां और ABI समस्याएं पैदा होंगी) . इस समय ऐसा करने का एकमात्र तरीका यह जांचना है कि संकलक -stdlib=libc++ का समर्थन करता है या नहीं और इसे जनरेटर अभिव्यक्ति के माध्यम से संकलक को पास करता है। इस बारे में अनपेक्षित चर शामिल कुछ भी नहीं है।

इसके अलावा, मैं आपके द्वारा महीनों पहले की गई एक टिप्पणी से सुधार करने के लिए एक टिप्पणी छोड़ने की सराहना नहीं करता, विशेष रूप से यह देखते हुए कि मैं अपने अगले प्रयास में मेसन पर सीएमके को लक्षित करूंगा। इसमें चातुर्य की कमी है, और मेरी राय में बातचीत में कुछ भी नहीं जोड़ता है।

सीएमके 3.0 इतना पुराना है कि अब समर्थित नहीं है (10 जून, 2014)। वर्तमान में किसी को भी सीएमके 3.10 से कम कुछ भी नहीं चलाना चाहिए, हालांकि वर्तमान समय में सीएमके 3.12 के साथ अद्यतित रहना पसंद किया जाता है।

और हां, आपके द्वारा दिया गया उदाहरण पूरी तरह से अनुशंसित है (मुझे लगता है कि सीगोल्ड ने भी ऐसा नहीं करने का उल्लेख किया है)।

और हाँ, मेरा मतलब था target_compile_features. ^।^;

हालांकि, CXX_STANDARD क्लैंग के लिए libc++ समर्थन सेट नहीं करता है क्योंकि क्लैंग डिफ़ॉल्ट रूप से linux पर libstdc++ का उपयोग करता है जब तक कि कॉन्फ़िगर नहीं किया जाता है (और इसे अधिकांश linux वितरणों पर डिफ़ॉल्ट रूप से libc++ का उपयोग करने के लिए कभी भी कॉन्फ़िगर नहीं किया जाता है, क्योंकि यह लिंकर त्रुटियों और ABI मुद्दों का कारण होगा)। इस समय ऐसा करने का एकमात्र तरीका यह जांचना है कि क्या संकलक -stdlib=libc++ का समर्थन करता है और इसे जनरेटर अभिव्यक्ति के माध्यम से संकलक को पास करता है। इस बारे में अनपेक्षित चर शामिल कुछ भी नहीं है।

वर्तमान टूलचेन सभी ऐसा करते हैं कि क्लैंग के लिए ठीक है, कम से कम सी ++ 14 के साथ जैसा कि मैं संकलित करता हूं (और कुछ सी ++ 17)।

इसके अलावा, मैं आपके द्वारा महीनों पहले की गई एक टिप्पणी से सुधार करने के लिए एक टिप्पणी छोड़ने की सराहना नहीं करता, विशेष रूप से यह देखते हुए कि मैं अपने अगले प्रयास में मेसन पर सीएमके को लक्षित करूंगा। इसमें चातुर्य की कमी है, और मेरी राय में बातचीत में कुछ भी नहीं जोड़ता है।

मैं क्षमा चाहता हूं, तारीख पर ध्यान नहीं दिया क्योंकि मैं बैकलॉग पढ़ रहा था (और यहां बहुत सारे बैकलॉग हैं)। मैंने अभी कुछ ऐसा देखा है जो किसी भी तरह के आधुनिक सुझावों के लिए बुरी तरह से गलत दिखाई देता है जो मैंने कुछ वर्षों से देखा है और इसके तुरंत बाद पोस्ट में कोई सुधार नहीं देखा, इस प्रकार गलत जानकारी का प्रचार नहीं करना चाहता था। :-)

इस समय ऐसा करने का एकमात्र तरीका यह जांचना है कि क्या संकलक -stdlib=libc++ का समर्थन करता है और इसे जनरेटर अभिव्यक्ति के माध्यम से संकलक को पास करता है।

हालाँकि हाँ, यह टूलचेन फ़ाइल का काम है, जो कभी भी किसी बिल्ड फ़ाइल में कभी भी प्रकट नहीं होना चाहिए, कभी भी .

इस बारे में अनपेक्षित चर शामिल कुछ भी नहीं है।

मैं केवल उन चरों का संदर्भ दे रहा था जो सेट किए गए हैं और फिर केवल एक ही स्थान पर कहीं और उपयोग किए जाते हैं, जो कि कई कारणों से सीगोल्ड में दूसरों के बीच अनुशंसित है।

सीएमके 3.0 इतना पुराना है कि अब समर्थित नहीं है (10 जून, 2014)। वर्तमान में किसी को भी सीएमके 3.10 से कम कुछ भी नहीं चलाना चाहिए, हालांकि वर्तमान समय में सीएमके 3.12 के साथ अद्यतित रहना पसंद किया जाता है।

उन्हें नहीं करना चाहिए, और फिर भी कुछ स्थान हैं। एक गेम इंजन के लिए जो अद्यतित रहने की कोशिश करता है और नवीनतम तकनीक के साथ, नवीनतम सीएमके पर रहना ठीक है। हालाँकि मैं पुराने संस्करणों जैसे 3.5 और कुछ मामलों में 3.4 पर अटकी हुई अत्यंत सक्रिय परियोजनाओं से अच्छी तरह वाकिफ हूं। वास्तव में, कुछ प्रसिद्ध सी पुस्तकालय अभी भी सीएमके 2.8 को लक्षित करते हैं (देखें: एसडीएल 2, libssh2, libgit2, आदि) यह सुनिश्चित करने के लिए गधे में एक बड़ा दर्द है।

हालाँकि हाँ, यह टूलचेन फ़ाइल का काम है, जो कभी भी किसी बिल्ड फ़ाइल में कभी भी प्रकट नहीं होना चाहिए।

यह धारणा बनाना (कि टूलचैन फाइलें अच्छी तरह से लिखी गई हैं और सभी संभावित सिस्टम और सीएमके के सभी संस्करणों को कवर करती हैं) वर्तमान सामान्य सी ++ पारिस्थितिकी तंत्र में परेशानी पूछ रही है। क्लैंग का उपयोग करते समय, पुस्तकालय द्वारा libstdc++ या libc++ (विशेषकर जब FetchContent कॉल के माध्यम से उपयोग किया जाता है) के लिए संकलन का विकल्प प्रदान करने की आवश्यकता होती है। CheckIncludeCXX और CheckCXXCompileFlag अभी भी कुछ झंडे के लिए जरूरी हैं जो जीसीसी के तहत मौजूद नहीं हैं लेकिन क्लैंग (और इसके विपरीत) के तहत मौजूद हैं। यहां प्राथमिक मुद्दा यह है कि कंपाइलर इंटरफेस ने बड़ी मात्रा में विचलन किया है और विक्रेताओं के बजाय संगतता विकल्पों को सुविधाजनक बनाने या यहां तक ​​​​कि एक सामान्य इंटरफ़ेस पर चर्चा करने के लिए समय व्यतीत करने के बजाय, यह व्यवहार हम पर जोर दिया जाता है, डेवलपर जब हम केवल कोड लिखना चाहते हैं। मेरा विश्वास करो, इस ग्रह पर कोई भी मेरे से सी और सी ++ बिल्ड सिस्टम और निर्भरता प्रबंधन की स्थिति के बारे में अधिक परेशान नहीं है, लेकिन सीएमके पर मौजूदा पुस्तकालयों के लिए व्यावहारिकता की आवश्यकता है। बिल्ड सिस्टम से सीएमके में जाने के बारे में अच्छी बात यह है कि हम गेट को नवीनतम और सबसे बड़ी सुविधाओं के साथ शुरू कर सकते हैं। समस्या बिल्ड सिस्टम का ठहराव बन जाती है क्योंकि कोई भी इसे छूना नहीं चाहता (उस बहादुर आत्मा को छोड़कर जिसने कोड जनरेशन बिल्ड स्क्रिप्ट को अलग-अलग स्क्रिप्ट में लात मारी), लेकिन यह सुनिश्चित करने के लिए कुछ काम की आवश्यकता होगी कि यह हाथ से बाहर न जाए (जो ऐसा इसलिए होगा क्योंकि... मेरा मतलब है कि यह एक बिल्ड सिस्टम है। वे हमेशा करते हैं)

मुझे एक ऐसा व्यक्ति होना चाहिए जो वास्तव में विशेष रूप से सीएमके में बिल्ड स्क्रिप्ट लिखने का आनंद लेता है;)।

यह धारणा बनाना (कि टूलचैन फाइलें अच्छी तरह से लिखी गई हैं और सभी संभावित सिस्टम और सीएमके के सभी संस्करणों को कवर करती हैं) वर्तमान सामान्य सी ++ पारिस्थितिकी तंत्र में परेशानी पूछ रही है। क्लैंग का उपयोग करते समय, पुस्तकालय द्वारा libstdc++ या libc++ (विशेषकर जब FetchContent कॉल के माध्यम से उपयोग किया जाता है) के लिए संकलन का विकल्प प्रदान करने की आवश्यकता होती है।

इस तरह की चीजें टूलचेन को पास की जाने वाली संपत्ति होनी चाहिए, जिस पर टूलचेन तब कार्य कर सकता है।

साथ ही यदि आपके पास बहुत ही अनूठा सेटअप है, तो टूलचैन फाइलों को शामिल करना पूरी तरह से उचित है, जैसे कि एक बहुत ही कस्टम एंड्रॉइड बिल्ड के लिए कहें या तो (हालांकि सेमेक टूलचेन के विस्तारित पोली सेट में लगभग वह सब कुछ शामिल है जिसकी मुझे अब तक आवश्यकता है)।

समस्या बिल्ड सिस्टम का ठहराव बन जाती है क्योंकि कोई भी इसे छूना नहीं चाहता (उस बहादुर आत्मा को छोड़कर जिसने कोड जनरेशन बिल्ड स्क्रिप्ट को अलग-अलग स्क्रिप्ट में लात मारी), लेकिन यह सुनिश्चित करने के लिए कुछ काम की आवश्यकता होगी कि यह हाथ से बाहर न जाए (जो ऐसा इसलिए होगा क्योंकि... मेरा मतलब है कि यह एक बिल्ड सिस्टम है। वे हमेशा करते हैं)

यह वास्तव में अब सीएमके को चुनने के लिए एक महान बिंदु है, इसमें अच्छे और बुरे दोनों के एक दशक से अधिक पूर्व अनुभव से निपटने के बाद उस काम का पालन करने के लिए मानकों का एक अच्छी तरह से परिभाषित सेट है।

मुझे एक ऐसा व्यक्ति होना चाहिए जो वास्तव में विशेष रूप से सीएमके में बिल्ड स्क्रिप्ट लिखने का आनंद लेता है;)।

मैं निश्चित रूप से विकल्पों की तुलना में इसका आनंद लेता हूं, हालांकि मैंने इसमें काफी देर तक लिखा है कि यह मेरे लिए समझ में आता है, हालांकि इसका निश्चित रूप से यह मतलब नहीं है कि यह सभी के लिए होगा। ^।^;

मैंने पिछले कुछ वर्षों में कई अलग-अलग बिल्ड सिस्टम का उपयोग किया है। जिसने हाल ही में मेरे लिए सबसे ज्यादा मायने रखा वह है सीएमके, लेकिन मैं निश्चित रूप से स्कैन की अपील देख सकता हूं और यह कितना लचीला है।

भले ही स्कैन सही नहीं है (बिल्ड सिस्टम क्या है?) यह काफी अच्छा हो सकता है।

• क्या यह आवश्यक सुविधाएँ प्रदान करता है?
• यह कितना ओवरहेड बनाता है?

यदि SCons दोनों बिंदुओं के लिए "काफी अच्छा" स्कोर करता है तो इसे रखें।

क्या आप में से किसी ने स्कैन्स को किसी अन्य चीज़ से बदलने का प्रस्ताव दिया है, वास्तव में यह जानने का प्रयास किया है कि गोडोट बिल्ड सिस्टम कैसे काम करता है?

एक संकेत के रूप में, यह अविश्वसनीय रूप से जटिल है और मुझे नहीं लगता कि कई (या कोई भी) परियोजनाएं हैं जो कई प्लेटफार्मों के लिए सीएमके बिल्डिंग का उपयोग कर रही हैं और एक ही समय में कई बिल्ड लक्ष्यों को कॉन्फ़िगर/संकलित करने की इजाजत देती है।

जिन लोगों ने कहा था कि "मैं गोडोट बिल्ड सिस्टम को किसी और जगह पोर्ट करूंगा" के सभी प्रयास अब तक बुरी तरह विफल रहे हैं, जब स्कॉन्स की देखभाल की जटिलता का एहसास हुआ।

मेरे लिए, यह अब तक नौकरी के लिए सबसे अच्छा उपकरण है। इसके करीब भी कुछ नहीं है। यदि आप लोग आधार संकलन समय के बारे में शिकायत करते हैं (जो एसएसडी के साथ एक मध्यम से उच्च अंत प्रणाली पर सिर्फ 4/5 सेकंड है), तो आपको वास्तव में सबसे पहले यह समझने की कोशिश करनी चाहिए कि गोडोट निर्माण करते समय क्या करता है और देखें कि यह सीएमके या किसी अन्य में कैसा प्रदर्शन करेगा। .

मैंने एक नज़र डाली। मुझे विश्वास नहीं है कि यह सीएमके या अन्य जगहों पर पूर्ववत है। लेकिन मैं भी आलसी हूँ;)। हम देखेंगे क्या होता है।

किसी ऐसे व्यक्ति के रूप में जिसने बेज़ल पोर्ट किया। मैं उस बिंदु पर पहुंचने में सक्षम था जहां गोडोट संपादक ने आइकन के बिना शुरुआत की थी।

मुझे पूरा यकीन है कि सीएमके उस मुकाम तक पहुंच सकता है।

पुनश्च. बड़ी मात्रा में प्लेटफार्मों के साथ निकटतम प्रतियोगी परियोजना Urho3d है।

मैंने सेमेक पर अपना बेज़ल परिणाम पुन: पेश किया।

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() {
}

सेमेक स्थापित करें

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

कृपया इसके साथ खेलें। संपादक के पास बेज़ल बिल्ड (कोई आइकन नहीं) जैसी ही समस्याएं हैं, लेकिन आपको यह नमूना मददगार लग सकता है।

ध्यान दें

• प्रतीक 71175b45f819e7cc5e4368dbf3e42abdd19af542 के रूप में काम करते हैं
• विजुअल स्क्रिप्ट और जीडीस्क्रिप्ट काम

@fire इसके लिए धन्यवाद। मुझे सुधार के लिए बहुत सी जगहें दिखाई देती हैं जो इन सीएमके फाइलों के रखरखाव को आसान बनाती हैं (और नई सुविधाओं या कंपाइलर झंडे जोड़ने में समय व्यतीत होता है)। मैं इस अगले सप्ताहांत से निपट सकता हूं, हालांकि, शेड्यूल लंबित है।

बहुत बढ़िया काम @fire. यह देखकर खुशी हुई कि यहां कोई व्यक्ति केवल एक से अधिक बिल्ड सिस्टम में कुछ उत्पन्न कर सकता है: मुस्कान:।

थोड़ा अपडेट। @fire के काम के निर्माण से निपटने के लिए मेरे पास आज कुछ डाउनटाइम था। दुर्भाग्य से, कोड जनरेशन स्क्रिप्ट अभी भी वर्तमान स्कैन सिस्टम के साथ बहुत कम एम्बेडेड हैं और उन्हें पूरी तरह से निकालने के लिए कुछ काम की आवश्यकता है (यह निश्चित रूप से मान रहा है कि मैं कोड को सही ढंग से पढ़ रहा हूं)। उस ने कहा, यह शायद एक अलग मुद्दा + पुल अनुरोध होगा। मैंने कुछ क्षेत्रों की पहचान की है जहां एक बाहरी टेम्पलेट फ़ाइल (या टेम्पलेट फ़ाइलों की श्रृंखला) का उपयोग किया जा सकता है। पायथन के पास टेम्प्लेट स्ट्रिंग्स के लिए समर्थन है और यह स्ट्रिंग्स को संसाधित करने, उन्हें एक सूची में जोड़ने, और फिर अधिक स्ट्रिंग्स को संसाधित करने, और उन्हें एक सूची में जोड़ने आदि के बजाय जीवन को थोड़ा आसान बना सकता है।

आदर्श रूप से, कोड जनरेशन स्क्रिप्ट को चलाने में सक्षम होना चाहिए जैसे कि वे निर्माण के ज्ञान के बिना निष्पादन योग्य थे। जब तक उचित फाइलें उन्हें पास कर दी जाती हैं, हमें किसी भी अन्य बिल्ड सिस्टम को पूरी तरह से पोर्ट करने के लिए जाना अच्छा होगा।

@ slurps-mad-rips यह निकालना कि आपके स्कैन सिस्टम से स्कैन में भी एक अच्छा विचार है। आप प्रक्रिया में बहुत अधिक तर्क रखते हुए जीआईएल को लटका सकते हैं और अपने निर्माण प्रदर्शन को चोट पहुंचा सकते हैं। कभी-कभी यह समानांतर में निर्माण करते समय कुछ फ़ाइल बंद/खुली दौड़ की स्थिति का कारण बनता है (हालांकि अक्सर फ़ाइल को संदर्भ में खोलकर हल किया जाता है)।

हैलो सभी को,

मैं इस स्थान का उपयोग लोगों को बंदरगाह पर सीएमके में अद्यतन रखने के लिए करने जा रहा हूं। यदि अनुरोध किया जाता है, तो मैं एक अलग मुद्दा बनाउंगा और वहां परिवर्तनों का ट्रैक रखूंगा, हालांकि यह एक अच्छा क्षेत्र है क्योंकि इसे चर्चा का एक बड़ा बैकलॉग मिला है और मुझे लगता है कि इतना संदर्भ खोना बेकार होगा।

मैंने खुद को पीछे कर लिया। मुझे अगले सप्ताह के लिए सीएमके पोर्ट से एक ब्रेक लेना होगा, जबकि मैं एक सम्मेलन में भाग लेता हूं, हालांकि आप यहां मेरे शुरुआती पोर्टिंग प्रयास के प्रयासों को देख सकते हैं। कृपया ध्यान रखें कि मैं वर्तमान मास्टर शाखा के साथ 1:1 रहने के लिए शूटिंग करने जा रहा हूं, और जैसे ही वे आते हैं, मैं परिवर्तनों को बलपूर्वक आगे बढ़ाऊंगा ताकि मैं एक रिबेस रख सकूं। जैसे-जैसे मैं स्थिरता के करीब पहुंचूंगा, मैं रिबेस के साथ काम करना आसान रखने के लिए पुल अनुरोध दर्ज करूंगा, साथ ही परिवर्तनों पर टिप्पणी करना या प्रश्न पूछना आसान बना दूंगा। मुझे लगता है कि सीएमके के लिए यह बंदरगाह न केवल करने योग्य है, लेकिन कम से कम यह एक और व्यक्ति (मुझे) को अच्छी तरह से जानता है कि गोडोट वास्तव में कैसे बनाया और बनाया गया है और मैं इसे शब्दों में डाल सकता हूं ताकि अन्य प्राप्त कर सकें निर्माण प्रणाली का एक विहंगम दृश्य। यह पोर्ट संभवतः लंबे समय में सभी के वर्कफ़्लो को आसान बना सकता है, विशेष रूप से रिलीज़ के साथ। मैं झूठ नहीं बोलने वाला, CONFIGURE_DEPENDS निन्जा के साथ मिश्रित फाइलों की ग्लोबिंग वास्तव में काफी अच्छी है।

एक आखिरी बात, मैं अत्यधिक सुझाव देता हूं कि आप सभी सहायक सीएमके मॉड्यूल पर एक चोटी लें क्योंकि मैंने लिखा है क्योंकि यदि आप अन्य सीएमके प्रोजेक्ट लिख रहे हैं, तो ये मॉड्यूल काम में आ सकते हैं।

क्या आप नवीनतम 3.1 अल्फ़ा में अपडेट करने में सक्षम थे? अल्फा एक अच्छा लक्ष्य हो सकता है। वर्तमान में निर्माण की कोशिश कर रहा है।

इस अंक का शीर्षक है बिल्डसिस्टम को मेसन पर ले जाने पर विचार करें । मुझे लगता है कि यहां सीएमके की चर्चा करना अनुचित है। सीएमके के बारे में चर्चा का अपना मुद्दा होना चाहिए। मेसन बनाम किसी और चीज की तुलना ठीक है।

@zaniar सामान्य रूप से बिल्ड सिस्टम के संबंध में इस धागे में बहुत चर्चा हुई है। सिर्फ इसलिए कि शीर्षक को अपडेट नहीं किया गया है इसका मतलब यह नहीं है कि हम अचानक एक नया मुद्दा बनाने जा रहे हैं और चर्चा के लिए वह सभी संदर्भ खो देंगे और फिर से शुरू करेंगे। मुझे लगता है कि हमें अचानक कई महीनों की चर्चाओं को दूर करने के लिए कहना अनुचित है।

@fire मैं पिछले कुछ हफ्तों से काम में व्यस्त हूं, मुझे शुक्रवार के लिए एक बड़ी समय सीमा मिली है, और उसके बाद मेरे पास अपना कांटा अप टू डेट करने के लिए कुछ समय हो सकता है। मुझे स्थानीय स्तर पर कुछ बदलाव मिले हैं, मैं पुश अप करना भूल गया लेकिन मेरे पास अभी समय नहीं है। (इस बिल्ड सिस्टम पोर्ट के बीच, मेरे gnu m4, 15 प्रस्तावों का कांटा जो मैं C++ मानकों सैन डिएगो मीटिंग और CppCon के लिए महीने के अंतिम सप्ताह में लिख रहा हूं, मैं पूरी तरह से दलदल में हूं, और मेरे पास दोष देने वाला कोई नहीं है लेकिन खुद)

हाँ, मेसन मूल चर्चा लक्ष्य था, लेकिन मुझे लगता है कि यह स्वाभाविक है कि अन्य निर्माण प्रणालियों को लाया गया है और चर्चा की गई है, और शायद इस मुद्दे के भीतर चर्चा को फैलाने के बजाय यहां पर चर्चा करना समझ में आता है, जैसे @slurps -mad-rips कहा।

मैं सीएमके में जाने से सहमत हूं। इसके टूलचेन के साथ इसका बहुत समर्थन है। उदाहरण के लिए एंड्रॉइड बिल्ड बहुत आसान हो जाता है, जो गोडोट अपनी एससीएसयूबी फाइल में कर रहा है, जो मुझे 'अनमटेनेबल' दिखता है।

एक ओपन सोर्स प्रोजेक्ट के रूप में, गोडोट को ऐसे समाधानों के साथ जाना चाहिए जो बनाए रखने में आसान हों और जो योगदानकर्ताओं को जानने और योगदान करने में सक्षम होने की अधिक संभावना हो।

साथ ही, मुझे लगता है कि यह GDNative अपनाने के लिए महत्वपूर्ण है। जो भी बिल्ड टूल का उपयोग किया जाता है, आसानी से संशोधित बिल्ड स्क्रिप्ट के साथ एक उदाहरण या मानक प्रोजेक्ट होना चाहिए जो आईओएस, एंड्रॉइड इत्यादि सहित सभी प्लेटफॉर्म के लिए बिल्डिंग का समर्थन करता है।

साथ ही सामान्य मॉड्यूल को साझा पुस्तकालयों के रूप में संकलित करने में सक्षम होना चाहिए। यह #19486 से संबंधित है ताकि इंजन को कई डाउनलोड करने योग्य घटकों में विभाजित किया जा सके।

मैं वास्तव में इनसे निपट रहा हूं। मैंने कुछ समय में अपने परिवर्तनों को आगे नहीं बढ़ाया है क्योंकि मैं आगामी सी ++ मानकों की बैठक सीपीपीकॉन में व्यस्त हूं, और हम अगले सप्ताह काम पर रिलीज कर रहे हैं। कहने के लिए पर्याप्त है, मेरे पास बंदरगाह को खत्म करने के लिए ज्यादा समय नहीं है, लेकिन मेरा अधिकांश समय पाइथन स्क्रिप्ट को तेज करने में खर्च किया जा रहा है जो आगे चलकर सी ++ कोड उत्पन्न करता है। मैं इस सप्ताह के अंत में अपने बंदरगाह पर काम फिर से शुरू करने की उम्मीद कर रहा हूं। मैं वर्तमान में मूल्यांकन कर रहा हूं कि स्वचालित रूप से तृतीय पक्ष निर्भरताओं को प्राप्त करना है और रेपो में संग्रहीत पैच लागू करना है या नहीं। कोर डेवलपर्स के लिए मेरे पास एक सवाल यह है कि वे मुख्य रेपो से बाहर और संगठन पर अपने स्वयं के भंडार में सभी तृतीय_पार्टी रेपो को तोड़ने के लिए कितने खुले होंगे। मैं अपनी परियोजनाओं में FetchContent पर काफी हद तक निर्भर हूं, और वर्तमान में मैं चाहता हूं कि मैं इन तृतीय पक्ष निर्भरताओं के लिए ऐसा कर सकूं जिन्हें थोड़ा फोर्क किया गया है। यह मुझे प्रत्येक तीसरे पक्ष के पुस्तकालय को पोर्ट किए जाने के बाद कोर रेपो में वृद्धिशील परिवर्तन करने के साथ-साथ उनकी सेमेक फाइलों को साफ करने के लिए भी काम करने देगा।

इसके अतिरिक्त ध्यान देना चाहिए, कि मैं इंजन को भी मॉड्यूलर करने की कोशिश कर रहा हूं, इसलिए इन घटकों को तकनीकी रूप से एक दूसरे से अलग किया जा अगर कोई इसे चाहता है। यह उस मुद्दे को खारिज कर सकता है जिसका

अंत में, मैं कोर डेवलपर्स के लिए कुछ अतिरिक्त बिल्ड टूल्स के लिए समर्थन जोड़ रहा हूं यदि वे सिस्टम पर पाए जाते हैं। क्लैंग-फॉर्मेट, क्लैंग-टिडी, ccache या sccache, distcc, क्लैंग-चेक, एड्रेस सैनिटाइज़र, ubsanitizer, थ्रेड सैनिटाइज़र, आदि जैसी चीजें। ये ज्यादातर लिंटर हैं (और कुछ लोगों के सिर चेतावनियों और विभिन्न त्रुटियों के साथ फट सकते हैं) वे पता लगा रहे हैं) लेकिन वे सक्षम करने के लिए वैकल्पिक होंगे। कम से कम sccache या ccache का उपयोग करने से बिल्ड और इसके विपरीत स्विच करने पर कुछ बिल्ड सुधार होगा। सीएमके 3.13 के रिलीज होने की प्रतीक्षा करना अच्छा होगा क्योंकि इससे कुछ कीचड़-कार्य हल हो जाएंगे जिन पर मुझे भरोसा करना है, लेकिन महत्वपूर्ण बात यह है कि मैं इसे स्थापित कर रहा हूं ताकि वर्तमान "आरंभ करना" वर्कफ़्लो है अभी भी pip install को Python 3.5 या बाद के संस्करण के माध्यम से चलाने के लिए, हालाँकि यह एक virtualenv के अंदर होगा ताकि लोगों को अपने सिस्टम के वातावरण के साथ खिलवाड़ न करना पड़े। (यह दूसरों को विभिन्न कोड जनरेशन स्क्रिप्ट के लिए निर्भरता के रूप में अतिरिक्त पायथन पुस्तकालयों का उपयोग करने के लिए प्रयोग करने की अनुमति देगा और बाद में उन्हें अनइंस्टॉल करना याद नहीं रखना होगा)

वैसे भी, अद्यतन अचानक जानकारी के लिए खेद है तुम सब डंप। मैं इस बंदरगाह को समाप्त करने के लिए समर्पित हूं, लेकिन जीवन हाल ही में रास्ते में आ गया है

मैं अपनी खुद की परियोजनाओं में FetchContent पर काफी हद तक भरोसा कर रहा हूं, और मैं वर्तमान में चाहता हूं कि मैं इन तृतीय पक्ष निर्भरताओं के लिए ऐसा कर सकूं जिन्हें थोड़ा फोर्क किया गया है।

आप हंटर का भी उपयोग कर सकते हैं और एक गोडोट-विशिष्ट कोड भंडार (उदाहरण के लिए जीथब पर एक विशेष गिट रेपो) बना सकते हैं और सभी निर्भरताओं तक पहुंच सकते हैं जैसे कि यह भवन, कैशिंग इत्यादि को संभालता है ... आवश्यक और ठीक से (या सभी निर्भरताओं को 'मुख्य' हंटर पैकेज रेपो में जमा करें और इसे सीधे उपयोग करें)। हंटर सिर्फ एक सेमेक फ़ाइल (HunterGate.cmake) है और इसे पैकेज रिपॉजिटरी जानकारी (चाहे आधिकारिक एक या एक कस्टम एक) प्राप्त करने के लिए एक कॉल है।

एक विनम्र अनुरोध: इस मुद्दे का टिप्पणी सूत्र बहुत बड़ा हो गया है - क्या कोई व्यक्ति जो इसका अनुसरण कर रहा है, वह एक टिप्पणी में अब तक की सामान्य चर्चा को संक्षेप में प्रस्तुत करने में सक्षम होगा (और शायद इसे @RiverMesa की प्रारंभिक पोस्ट से जोड़ा जा सकता है)?

सभी को नमस्कार। मैं एक छोटा खेल बनाने के लिए अपने अगले इंजन के रूप में गोडोट का उपयोग करने की योजना बना रहा हूं।

मैंने इस बातचीत को देखा और एक ऐसे व्यक्ति के रूप में जिसे सीएमके और मेसन (और ऑटोटूल, ट्यूप, प्लेन मेक, वाफ, स्कैन्स, इन सभी टूल्स में पूर्ण प्रोजेक्ट की कोशिश कर रहा है...) का अनुभव है, मैं अपनी प्रतिक्रिया देना चाहता था।

जिन प्रणालियों का मैंने अधिक गहनता से उपयोग किया है वे हैं ऑटोटूलस, सीएमके और मेसन। मैं पिछले वर्षों से मेसन और सीएमके का उपयोग कर रहा हूं, क्योंकि मैंने उत्पादन सेटअप में अन्य सभी बिल्ड सिस्टम को पहले ही त्याग दिया है।

सेमेक के फायदे

• परिपक्व प्रोजेक्ट जेनरेटर यदि आप विजुअल स्टूडियो की परवाह करते हैं (मुझे लगता है कि मेसन आजकल इसका अच्छी तरह से समर्थन करता है लेकिन हाल ही में कोशिश नहीं की है) और विशेष रूप से एक्सकोड (निश्चित रूप से यहां इसकी कमी है)।
• व्यापक रूप से अपनाना, IDEs में अधिक समर्थन
• व्यापक रूप से अपनाना -> योगदान प्राप्त करना आसान (हालांकि मेसन सीखने के लिए एक हवा है मुझे कहना चाहिए)

मेसन के लाभ

• डिफ़ॉल्ट रूप से कई उपयोगी लक्ष्य: सैनिटाइज़र, एकता मुफ़्त में बनाता है, मुफ़्त में पहले से तैयार हेडर, मुफ़्त में कवरेज...
• दस्तावेज सीएमके दस्तावेज से गधे को बाहर निकालता है: http://mesonbuild.com/
• मुझे क्रॉस संकलन बहुत आसान लगा
• मेसन के पास हर काम करने का एक स्पष्ट तरीका है

मैं कौन सा चुनूंगा? यदि क्रॉस-संकलन गहन होने जा रहा है तो मैं मेसन को चुनूंगा और आप तेजी से संकलन-समय की परवाह करते हैं (एकता बनाता है और प्रीकंपिल्ड हेडर डिफ़ॉल्ट रूप से समर्थित होते हैं)।
मैं सीएमके पर विचार करूंगा क्योंकि यह मानक है और टीम के लिए योगदान महत्वपूर्ण हो सकता है। मैं खुद मेसन को व्यक्तिगत रूप से चुनूंगा, लेकिन यह सिर्फ एक व्यक्तिगत राय है, क्योंकि मुझे उपकरण बेहतर लगता है और इससे मेरा अपना समय बचता है (सीएमके स्क्रिप्टिंग, स्पेस हैंडलिंग, जनरेटर एक्सप्रेशन, आदि ... मैं आपको देख रहा हूं)।

नीचे इस बेशर्म आत्म-प्रचार के लिए क्षमा करें, लेकिन मुझे लगता है कि संदर्भ इसके लिए भीख माँग रहा है।

मेरे पास कमोबेश बुनियादी मेसन के बारे में लेखों की एक छोटी श्रृंखला है यदि कोई उत्सुक है (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 यह एक महान लेखन है - मैं थोड़ी देर के लिए इस मुद्दे का पालन कर रहा हूं और यह अद्भुत होगा यदि मैं गोडोट + क्लियन के साथ काम कर सकता हूं, जो दुख की बात है कि सीएमके ही है।

हाँ अधिकांश आधुनिक आईडीई या तो केवल सीएमके हैं, और/या कुछ कस्टम बिल्ड सिस्टम, और/या 'कच्ची कॉल' जो बहुत सारी सुविधाएं खो देती हैं। सीएमके वास्तव में मानक बन गया है, चाहे वह योग्य हो या नहीं।

@dorkbox अगर मैं इन परिवर्तनों को प्राप्त कर सकता हूं

@germandiago

CppCon 2018 के रूप में मेसन के लेखक के साथ अब मैं वास्तव में दोस्त हूं (अधिक या कम )। उक्त बैठक में उनका पेपर (यह अगले सप्ताह है, वास्तव में!), और हम भी CppCon में उसी बिल्ड सिस्टम पैनल पर थे।

मुझे मेसन का उपयोग करना अच्छा लगेगा। यदि आप धागे में आगे पढ़ते हैं, तो मैंने मेसन पोर्ट की कोशिश की थी, लेकिन उस समय स्कोन के साथ चीजें बहुत एकीकृत थीं। मैं अभी भी वर्तमान कोड जनरेशन स्क्रिप्ट को अलग 'निष्पादन योग्य' स्क्रिप्ट के रूप में निकाल रहा हूं ताकि भविष्य में, मेसन के लिए एक कदम सवाल से बाहर न हो। हालांकि यह धीमा काम है, और मैंने कोड जनरेशन में मदद के लिए कुछ जिन्जा टेम्पलेट्स लिखना शुरू कर दिया है ताकि स्कोन पूरी तरह से गिराए जा सकें। उस ने कहा, जबकि मेरा सार्वजनिक कांटा पुराना है, जो मेरे पास घर पर है वह थोड़ा आगे है (और एक निजी कांटा के साथ समन्वयित)। काम दुर्भाग्य से रास्ते में आ गया है, और सैन डिएगो दुर्भाग्य से मेरा अधिक समय 'चोरी' करने वाला है। उसके बाद, हालांकि, मुझे अपने निजी कांटे पर मेरे कुछ स्थानीय प्रयोगों को हटाने के लिए स्वतंत्र होना चाहिए और अंत में गोडोट सेमेक ट्रेन पर वापस जाना चाहिए। मैं यह सुनिश्चित करने के लिए प्रतिबद्ध हूं कि वर्तमान वर्कफ़्लो प्रक्रिया में बड़े पैमाने पर व्यवधान के बिना एक पूर्ण पुल अनुरोध जा सकता है।

(एक तरफ के रूप में: इस पर काम करते समय आपके धैर्य के लिए सभी को धन्यवाद। मुझे पता है कि इसे शुरू किए हुए कुछ

हाँ अधिकांश आधुनिक आईडीई या तो केवल सीएमके हैं, और/या कुछ कस्टम बिल्ड सिस्टम, और/या 'कच्ची कॉल' जो बहुत सारी सुविधाएं खो देती हैं। सीएमके वास्तव में मानक बन गया है, चाहे वह योग्य हो या नहीं।

आईडीई के साथ मेसन का उपयोग करने के लिए एक संभावित उपयोगी उपकरण:

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

यह आईडीई को लगता है कि यह सीएमके का उपयोग कर रहा है, लेकिन वास्तव में हुड के नीचे मेसन का उपयोग कर रहा है।

कुछ पृष्ठभूमि: मैं कई (10?) वर्षों से सीएमके का बहुत बड़ा प्रस्तावक था, लेकिन पिछले साल या तो मेसन से प्यार हो गया। मेसन को सीएमके की कई परेशानियों को ठीक करने/रोकने के दौरान सीएमके की उपयोगी सुविधाओं के इरादे से लिखा गया प्रतीत होता है। एक परियोजना में मेसन को अपनाने के लिए मुझे वर्तमान में एक बाधा का सामना करना पड़ रहा है जो आईडीई समर्थन है। मैंने अभी उपरोक्त टूल की खोज की है, तो शायद इससे मदद मिलेगी।

सभी और हर निर्माण प्रणाली में इसकी प्रमुख खामियां हैं, इससे अधिक, तकनीकी दृष्टि से इसे बदलने का कोई कारण नहीं है, चाहे वह स्कैन, ऑटोटूल, सेमेक, मेसन, या जो कुछ भी बना बनाम निंजा आपका धर्म हो। मुझे लगता है कि इस के डुप्लिकेट के रूप में अन्य सभी बिल्ड सिस्टम परिवर्तन बग को बंद करना बहुत अच्छा होगा।

<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 :)।

कमरे में 800lb गोरिल्ला जिसका अभी तक उल्लेख नहीं किया गया है। गोडोट के प्रसिद्धि के दावों में से एक क्रॉस प्लेटफॉर्म संगतता है। इसका पालन करना चाहिए कि जो भी निर्माण प्रणाली है जिसमें माइग्रेट करने की क्षमता है, गोडोट द्वारा लक्षित सभी प्लेटफार्मों पर उपलब्ध और परीक्षण किया जाना चाहिए। जो भी इस तरह के माइग्रेशन के पीछे है, उसे सभी समर्थित प्लेटफॉर्म पर माइग्रेशन का परीक्षण करने के लिए इच्छुक होना चाहिए, या कम से कम उस टीम का हिस्सा होना चाहिए जो ऐसा कर रही है। अन्यथा मैं इस तरह के कदम को गोडोट दर्शन के विपरीत और आम तौर पर सिर्फ एक बुरे विचार के रूप में देखता।

@lazybulfrog मेरे पास डेस्कटॉप के लिए लगभग 5 अलग-अलग मशीनों और कई मोबाइल उपकरणों तक पहुंच है। सेमेक के लिए मेरे बंदरगाह का एक हिस्सा यह सुनिश्चित कर रहा है कि सभी मौजूदा प्लेटफार्मों के लिए सेमेक टूलचेन उपलब्ध हैं।

@ slurps-mad-rips उन हाइकू में से एक है? यदि नहीं, तो मैं परीक्षण में मदद करने को तैयार हूं। धन्यवाद।

सेमेक के लिए मेरे बंदरगाह का एक हिस्सा यह सुनिश्चित कर रहा है कि सभी मौजूदा प्लेटफार्मों के लिए सेमेक टूलचेन उपलब्ध हैं।

यह भी न भूलें कि यदि आपको किसी प्लेटफ़ॉर्म के लिए cmake टूलचेन की आवश्यकता है तो संभवतः https://github.com/ruslo/polly पर एक प्रीबिल्ट है और यदि नहीं है तो आपको इसे पीआर करना चाहिए। :-)

@ slurps-mad-rips यह कैसा चल रहा है? मैंने देखा है कि आपने 14 जनवरी को कोड अपडेट किया था। मैंने विंडोज़ पर संकलन करने की कोशिश की लेकिन उसे pkgconfig नहीं मिला।

@फायर लाइफ ने मेरे रास्ते में कुछ करनी पड़ी । व्यक्तिगत सामान, दुर्भाग्य से। मैं काम पर ध्यान केंद्रित कर रहा हूं और आईएक्सएम लाइब्रेरी को खत्म कर रहा हूं जिसका उपयोग मैं काम की मात्रा को कम करने के लिए कर रहा हूं जिसे गोडोट में कॉपी किया जाएगा। सौभाग्य से मैं एक सप्ताह में छुट्टी ले रहा हूं (मैं इस सप्ताह के अंत में इस तिमाही के लिए WG21 आईएसओ बैठक के लिए कोना जा रहा हूं) इसलिए मेरे पास इस पर काम करने के लिए कुछ खाली समय होगा, और (उम्मीद है!) मेरे पास होगा macOS, Linux, और Windows के लिए जल्द ही एक कार्यशील बिल्ड™। एंड्रॉइड और आईओएस, उसके बाद फ्रीबीएसडी और हाइकू (क्षमा करें @lazybulfrog , हालांकि आप जल्दी/अक्सर परीक्षण करने के लिए स्वागत से अधिक हैं) उसके बाद मेरी अगली प्राथमिकता होगी।

काम/अवरोधक का सबसे बड़ा हिस्सा अब तक पाइथन स्क्रिप्ट को "इंस्टॉल करने योग्य" टूल में निकाल रहा है जो स्कैन से अलग हैं और प्रक्रियाओं की तरह निष्पादित होते हैं। निर्भरता, सेटिंग्स, आदि की वास्तविक हथियाने की तुलना में आसान रहा है।

@ slurps-mad-rips, जीवन ने मुझे कुछ वक्र गेंदें भी फेंक दी हैं। शायद हमें बेसबॉल टीम शुरू करनी चाहिए। मैं

सौभाग्य से उन वक्र गेंदों में से एक जब से मैंने पिछली बार टिप्पणी की थी, हाइकू और फ्रीबीएसडी के साथ 32 जीबी रैम के साथ 8 कोर ज़ीऑन था। शायद जल्द ही मुझे दोनों का परीक्षण करने में मदद करने के लिए कुछ समय मिलेगा।

मैं वास्तव में उत्साहित हूं कि इन दोनों प्लेटफार्मों पर ध्यान दिया जा रहा है। जल्द ही परीक्षण के लिए तत्पर हैं।

मुझे लगता है कि कई बिल्ड-सिस्टम होना उचित है। शायद एक आधिकारिक बिल्ड-सिस्टम जो अच्छी तरह से समर्थित है और अन्य "आप इसे समझते हैं" आधार पर प्रदान करते हैं। उपयोगकर्ता अपने स्वयं के बिल्ड-सिस्टम का उपयोग करना चाहेंगे, तो क्यों न अपने काम को एक ही स्थान पर रखा जाए?

अगर चीजें इस तरह से चलती हैं तो मैं एक बाजेल बंदरगाह में योगदान करने को तैयार हूं।

मुझे लगता है कि कई बिल्ड-सिस्टम होना उचित है। शायद एक आधिकारिक बिल्ड-सिस्टम जो अच्छी तरह से समर्थित है और अन्य "आप इसे समझते हैं" आधार पर प्रदान करते हैं। उपयोगकर्ता अपने स्वयं के बिल्ड-सिस्टम का उपयोग करना चाहेंगे, तो क्यों न अपने काम को एक ही स्थान पर रखा जाए?

एक लिनक्स पैकेजर के रूप में, मैंने विभिन्न बिल्ड सिस्टम के साथ सैकड़ों प्रोजेक्ट देखे हैं। मैंने कुछ ऐसे देखे हैं जिनमें कई बिल्ड सिस्टम उपलब्ध थे। मैंने कभी ऐसा नहीं देखा जहां यह पूरी तरह से गड़बड़ नहीं था, खासकर जब वैकल्पिक बिल्ड सिस्टम को पहली बार योगदान दिया गया था "कृपया सीएमके जोड़ें यह बहुत अच्छा है" योगदानकर्ता जो तब परियोजना से गायब हो गए थे, और अनुरक्षकों ने इसे अपडेट करने की जहमत नहीं उठाई।

वहाँ कई buildsystems के समर्थन में सब पर कोई मूल्य है, और मैं किसी भी पीआर कि दिशा में जा विलय नहीं होगा। मैं मुख्य बिल्डिस सिस्टम अनुरक्षकों में से एक हूं, और जब भी हमें कुछ बदलने की आवश्यकता होती है, तो मैं निश्चित रूप से वैकल्पिक बनाए रखने का बोझ नहीं उठाना चाहता।

वर्तमान में हमारे पास एक बिल्डसिस्टम है जो सभी के लिए काम करता है और अच्छी तरह से समर्थित है, और बदलने का कोई इरादा नहीं है। यदि कोई वास्तव में अन्य विकल्पों की जांच करना चाहता है, तो बेझिझक, और यदि अंतिम परिणाम भी सभी के लिए काम करता है, अच्छी तरह से समर्थित हो सकता है और बड़ी कमियों के बिना अतिरिक्त मूल्य प्रदान करता है, तो हम इस पर विचार करेंगे।

यदि कोई _वास्तव में अन्य विकल्पों की जांच करना चाहता है, तो बेझिझक, और यदि अंतिम परिणाम भी सभी के लिए काम करता है, अच्छी तरह से समर्थित हो सकता है और बड़ी कमियों के बिना अतिरिक्त मूल्य प्रदान करता है, तो हम इस पर विचार करेंगे।

मैं अपने सीएमके पोर्ट के साथ यही कर रहा हूं। वर्तमान में स्कैन के तहत एक नो-ऑप या सिंगल फ़ाइल परिवर्तन मेरी वर्तमान मशीन (जिसमें 64GB RAM, तुलनीय प्रोसेसर, आदि है) पर 10 सेकंड से अधिक समय लगता है। निंजा + सेमेक के साथ संपूर्ण कॉन्फ़िगरेशन + जनरेट प्रक्रिया में कम समय लगता है, और निंजा बिना ऑप बिल्ड में 0.2 सेकंड से कम समय में बिल्ड फिनिश (खिड़कियों पर, जहां एक प्रक्रिया शुरू करना महंगा है)। मैं मोज़िला से sccache टूल का उपयोग करने में भी सक्षम हूं यदि यह स्थापित है, और यह कोडजन भागों को संपादित करने/स्क्रैच से पुनर्जीवित निर्माण चलाने के लिए बेहद उपयोगी रहा है ताकि यह सुनिश्चित हो सके कि कुछ भी मेरे स्थानीय पर्यावरण पर निर्भर नहीं है।

मेरा अधिकांश समय कोड जनरेशन स्क्रिप्ट को पायथन लिपियों में निकालने में बिताया गया है जो अपने आप चल सकती हैं। अगर केवल यही चीज गोडोट में विलीन हो जाती, तो इस पर बिताया गया मेरा समय कुल बर्बाद नहीं होता। यह run_in_subprocess हैक को भी हल करता है जो वर्तमान में समानांतर के साथ विंडोज़ पर मुद्दों को हल करने के लिए मौजूद है।

मैं अभी-अभी अपनी यात्रा से लौटा हूँ और थोड़ा सा काम करने में सक्षम था। अभी मुझे मैन्युअल स्कैन चलाने से कुछ फ़ाइलों की प्रतिलिपि बनाने की आवश्यकता है, लेकिन समय बीतने के साथ-साथ मैं जेनरेट किए गए स्रोतों से दूर जा रहा हूं। license.gen.h और method_bind.inc हेडर वर्तमान में मेरा सबसे बड़ा लक्ष्य हैं, लेकिन इससे पहले कि मैं उनसे निपटूं, जेटलैग + काम से निपटने के लिए मुझे कुछ दिन लग रहे हैं।

(यह भी सिर्फ cc @fire जा रहा है क्योंकि वह इस प्रगति में थोड़ी दिलचस्पी रखता है)

मेरे अनुभव से विंडोज़ पर एंड्रॉइड बनाते समय मेसन पूरी तरह से एफ * एड अप है, मैं इसे तीसरे पक्ष के पुस्तकालयों में से एक को संकलित करने के लिए काम नहीं कर सकता जो इसका उपयोग करता है (लिबपॉक्सी)। और मुझे लगता है कि यह कंक्रीट कंपाइलर सामान से बहुत अधिक जुड़ा हुआ है।

मेरी इच्छा केवल एक बिल्ड सिस्टम है जो बिल्ड कमांड से अलग से प्रोजेक्ट फाइल और डेटाबेस फाइल जेनरेट कर सकती है।

हर बार जब मैं फाइलों में बड़े बदलावों के साथ एक नई शाखा की जांच करता हूं, तो मुझे अपनी बनामप्रोज फाइलों को पुन: उत्पन्न करने के लिए कमांड लाइन से स्कैन चलाना पड़ता है, जो किसी भी तरह से पूर्ण निर्माण का कारण बनता है। मैंने जो देखा है उससे स्कैन्स में, किसी भी प्रकार का कोई प्रोजेक्ट जनरेशन चरण नहीं है। यही कारण है कि यह क्लैंग-टूल्स में उपयोग के लिए बॉक्स से बाहर संकलन डेटाबेस बनाने का समर्थन नहीं करता है।

वर्तमान में, विंडोज़ (आईडीई-वार) पर गोडोट को कोड करने का एकमात्र व्यवहार्य समाधान विजुअल स्टूडियो के पास है, अन्यथा केवल टेक्स्ट-एडिटर का उपयोग करने के लिए तैयार रहें।

स्कैन्स अद्भुत और सभी हैं, लेकिन जब मेरे पास 12 कोर थ्रेड्रिपर और 128 जीबी रैम है और मुझे सिंगल लाइन परिवर्तन को संकलित करने के लिए विंडोज़ पर 12+ सेकेंड इंतजार करना पड़ता है (उनमें से अधिकतर स्कैन सोच है), यह थोड़ा परेशान हो जाता है।

लेकिन स्कैन के लिए वास्तविक नकारात्मक पक्ष (और यह खोज में मेरा आलस्य हो सकता है) यह है कि मैं व्यक्तिगत सीपीपी फाइलों को संकलित नहीं कर सकता। पूरी परियोजना के निर्माण के बिना अलग-अलग सीपीपी फाइलों को संकलित करने में सक्षम होने के नाते एक बड़ा उत्पादकता बूस्टर और सैनिटी चेकर है।

यह सिर्फ लाइन में बदलाव नहीं है जिसमें समय लगता है, यहां तक ​​​​कि यह पता लगाना कि क्या कुछ भी बनाने में समय लगता है ...

गिट-बैश से चल रहा है:

$ 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

बस यह जोड़ना चाहता था कि सीएमके का नवीनतम संस्करण कुछ गायब सुविधाओं को जोड़ रहा है जिनका उल्लेख लोगों ने इसका उपयोग न करने के कारणों के रूप में किया था।
एकता बनाता है: https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
पहले से संकलित हेडर: https://cmake.org/cmake/help/latest/command/target_precompile_headers.html

@Nosliwnayr उन दोनों को कई वर्षों से

@bdbaddog
मुझे समझ में नहीं आता, क्या मुझे हर एक फाइल को मैन्युअल रूप से निर्दिष्ट करना है? वह क्या करता है .obj बात क्या करती है?
मैं इसे पूरी परियोजना पर कैसे लागू करूं? क्या यह स्वचालित रूप से व्यक्तिगत फाइलों को पुन: संकलित करता है?

मुझे उम्मीद है कि संकलन के समय को और अधिक अनुकूलित किया जा सकता है, बिना किसी चाल के तुरंत सी ++ कोड संकलित करने में सक्षम होने के कारण भगवान भेजना होगा - यह देखने के बाद कि गोडोट कितनी तेजी से संकलित करता है, मैं वास्तव में अवास्तविक इंजन 4 पर वापस जाने के लिए संघर्ष कर रहा हूं (इसे संकलित करना , मुझे ४५ मिनट लगे, लेकिन अब इंजन किसी तरह अधिक फूला हुआ हो गया, और इसमें ६० मिनट तक का समय लगता है, जो कि पागल है)

मेरा मतलब है कि मुझे लगता है कि गोडोट में और भी तेजी से संकलन करने की क्षमता है, और मैं खुद बिल्ड सिस्टम को बदल दूंगा, लेकिन मेरे पास 0 अनुभव है, इसलिए मुझे सचमुच पता नहीं होगा कि क्या करना है

@Nosliwnayr
क्या हम कृपया पूर्व संकलित हेडर से बच सकते हैं? मुझे लगता है कि वे पूर्ण कचरा हैं, बस इसे सरल रखें

वे शेयरिंग प्रोजेक्ट भी बना रहे हैं, जिस तरह से और अधिक कष्टप्रद है, और यह मेरे दिमाग में बहुत अधिक डाउनसाइड्स के साथ कभी खत्म नहीं होता है - लेकिन हे, अगर किसी ने उन्हें प्रभावी ढंग से इस्तेमाल किया, तो मैं अच्छा हूं, लेकिन मेरे लिए वे एक गंदी चाल की तरह लगते हैं, इसके बजाय एक सच्चे अनुकूलन का, और मुझे ईमानदार होने के लिए सस्ते तरकीबें पसंद नहीं हैं

अवास्तविक इंजन 4 का उपयोग करने के बाद, मैं पूर्व संकलित बकवास के 20 जीबी मूल्य से थक गया हूं, मुझे नहीं लगता कि वे इसके लायक हैं, एक कम बेवकूफ प्रणाली होनी चाहिए (असत्य इंजन 4, 60 तक ले लिया - मेरे लिए 80 जीबी, अच्छा नहीं)

अगर गोडोट उस दिशा में जाता है, तो मैं मान लूंगा कि डेवलपर्स ने अपने भगवान को खो दिया है

नरक, भाड़ में जाओ, मैं उन्हें scons से चिपकना चाहता हूं, अगर यह असत्य इंजन 4 की पागलपन की गेंद से बचा जाता है, तो मुझे लगता है कि बेहतर दृष्टिकोण, scons में सुधार करना होगा, इसे पूरी तरह से बदलने के बजाय, एक पूरी नई टूटी हुई गधे के साथ संकलन प्रणाली, जब वर्तमान काम करता है ... कम या ज्यादा

मुझे लगता है कि एक नई प्रणाली में आगे बढ़ने के लिए आवश्यक मानसिक प्रयास, हमारे पास पहले से मौजूद चीजों में सुधार करने की तुलना में अधिक है, और नया कंपाइलर महीनों तक कार्यात्मक रूप से टूट सकता है

मुझे यकीन है कि अगर यह हो जाता है तो नरक शिकायत नहीं करेगा, लेकिन इस तरह के एक महत्वपूर्ण इंजन घटक के साथ, आपको बहुत कुछ करना होगा, इस बदलाव के बाद कोई पीछे नहीं हटेगा

@ RaTcHeT302 - निर्दिष्ट कमांड लाइन यह है कि यदि आप केवल एक लक्ष्य (इस मामले में एक ऑब्जेक्ट फ़ाइल) को स्पष्ट रूप से संकलित करना चाहते हैं (और निश्चित रूप से जिन फ़ाइलों पर यह निर्भर करता है)

वास्तव में यदि स्कैन के साथ समस्याओं के बारे में शिकायत करने वाले सभी लोग एक जटिल निर्माण प्रणाली को दूसरे नए चमकदार सिस्टम में बदलने का सुझाव देने के बजाय उन्हें ठीक करने में मदद करने में योगदान देंगे .. तो ऐसी कई चिंताओं को ठीक किया जाएगा ..

@bdbaddog स्कैन इंटरमीडिएट स्टेज बिल्ड फाइल जेनरेट नहीं करता है। यह "परियोजना निर्भरता" चरण उसी चरण में करता है जैसे यह संकलित करता है, और उन्हें अलग नहीं किया जा सकता है।

यह आपके बिल्ड टूल को हिट करने से पहले सीएमके को हर बार प्रोजेक्ट फाइल जेनरेट करने के लिए कहता है, चाहे वह एमएसवीसी हो, निंजा-बिल्ड, मेक, एलवीएम, अपना जहर चुनें।

यदि मैं गिट शाखाओं को स्विच करता हूं, तो मैं उचित .vsproj और .sln फ़ाइलों को पुन: उत्पन्न करने के लिए स्कैन कमांड लाइन बिल्ड किए बिना विजुअल स्टूडियो को अपडेट नहीं कर सकता - और मैं लगभग हमेशा बिल्ड शाखा परिवर्तनों को साफ करता हूं क्योंकि मैं अतीत में मुद्दों में भाग गया हूं।

वे मध्यवर्ती फाइलें सिर्फ निर्माण के लिए नहीं हैं, उनका उपयोग स्थिर विश्लेषक और अन्य परियोजनाओं द्वारा भी किया जा सकता है।

जबकि मैं मानता हूं कि सेमेक सही नहीं है (मुझे यह उतना पसंद नहीं है), और मैं अजगर के लचीलेपन को पसंद करूंगा, सेमेक में टेबल पर सभी बिल्ड टूल्स का सबसे अच्छा एकीकरण और समर्थन है।

मेरे कांटे को सीएमके में परिवर्तित करते समय अधिकांश जटिलता कोड जनरेशन फाइलों में थी। यह विचार कि निर्माण जटिल है एक भ्रम है। बिल्ड को स्कैन की आवश्यकता नहीं है क्योंकि यह जटिल है। यह जटिल है क्योंकि यह स्कैन का उपयोग करता है।

इसके साथ ही, मैंने काम रोकने का कारण यह है कि मैं 2019 में जीडीसी में प्रमुख देवों से मिला (गिटहब मीटअप में) और उन्होंने कहा कि उनका कुछ अधिक उपयोगी होने का कोई इरादा नहीं है, यह कहते हुए कि वे करना पसंद करेंगे पूरी तरह से लिनक्स पर निर्माण और वास्तव में मैंने जो देखा है उससे वे ईयूएलए का उल्लंघन कर रहे हैं कि ऐप्पल को क्रॉस संकलन के लिए बिल्ड टूल्स स्थापित करने की स्वीकृति की आवश्यकता है।

प्रभारी लोगों की मानसिकता बहुत अधिक "साधनों को सही ठहराती है" और बिल्ड को सॉफ़्टवेयर के रूप में मानने के बारे में कोई परवाह नहीं है, और इसके बजाय गोडोट इसे स्क्रिप्ट की एक श्रृंखला के रूप में मानता है जो एक निर्माण का निर्माण होता है।

मैं कोड जनरेशन में किए गए परिवर्तनों को गोडोट में योगदान नहीं दूंगा (हालांकि यह अधिक पठनीय और तेज होने के बावजूद), और मैंने पूरी तरह से इस इंजन को छोड़ दिया है और अपने जीवन के साथ आगे बढ़ गया है। अगर मैं ईमानदार हूं तो मुझे ज्यादा खुशी होती है। इंजन में पहले से ही काफी तकनीकी ऋण है और मुझे लगता है कि यह लगभग 3 वर्षों में एक मुद्दा है, खासकर जब सी ++ मानक समिति टूलिंग तकनीकी रिपोर्ट पर काम कर रही है (मैं इसमें शामिल हूं और विकल्प फाइलों को मानकीकृत करने जैसी चीजों पर जोर दे रहा हूं एक हद तक, लेकिन यह सिर्फ एक तकनीकी रिपोर्ट है इसलिए कुछ लोग इससे अलग हो जाएंगे)।

यह भी शर्म की बात है। मेरा सीएमके बिल्ड स्थिर विश्लेषण त्रुटियों के एक समूह को पकड़ने में सक्षम था, जिसके कारण कई मुद्दे सामने आए हैं और आसानी से हल किए जा सकते हैं, लेकिन मैं जीडीसी में इस बारे में बग फाइल करने या यहां तक ​​​​कि ठीक करने का प्रयास करने के लिए देवताओं के साथ बहस करने से भी जल गया हूं। उन्हें। मेरी ऊर्जा और मेरा मानसिक स्वास्थ्य कहीं और बेहतर तरीके से खर्च होता है।

ऐसी कोई दुनिया नहीं है जहां स्कैन आने वाले सी ++ 20 मॉड्यूल डिज़ाइन को संभालने में सक्षम होंगे, जितना मैंने चिल्लाया है कि यह कई टूल्स को कैसे तोड़ देगा। यह उसके लिए निर्भरता ट्रैकिंग को संभाल नहीं सकता है, और इसके लिए एक पूर्व-स्कैन चरण की आवश्यकता होगी, जो निर्भरता ट्रैकिंग को और भी धीमा कर देगा।

अंत में, मैं लोगों को सुझाव देने जा रहा हूं कि वे ऐसे टूल को बेहतर बनाने की कोशिश न करें जो केवल मामूली बदलावों को स्वीकार कर सके। लोगों को यहां जो सुधार चाहिए, उसे प्राप्त करने के लिए स्कैन्स को जमीन से पूरी तरह से पुनर्लेखन और बड़ी संख्या में ब्रेकिंग परिवर्तनों की आवश्यकता होगी।

मेरा सुझाव है कि इस मुद्दे को बंद कर दिया जाए क्योंकि जीडीसी 2019 में बिल्ड सिस्टम को बदलने की चर्चा का उत्तर दिया गया था, लेकिन लीड इस मुद्दे पर टिप्पणी करने के लिए अपना समय बर्बाद करने के लायक भी नहीं समझते हैं, जो मुझे लगता है कि दिखाता है कि वे एर्गोनॉमिक्स की कितनी परवाह करते हैं विकास का।

मुझे ऐसा लगता है जैसे कि मौजूदा बिल्ड सिस्टम को प्लग एंड प्ले फैशन में 100% रूपांतरित कर दिया गया था, तो देवों के स्विच न करने का कोई कारण नहीं होगा।

केवल Linux पर निर्माण करना बेकार है। एक गेम इंजन जो विंडोज़ पर नहीं चलता है, किसी भी गंभीर गेम डेवलपर्स को रोक देगा।

मैं इस धारणा के तहत रहना चाहता हूं कि गेम डेवलपर्स अपने उपयोगकर्ताओं को संतुष्ट करने के लिए बिल्ड सिस्टम को बदलने के लिए पर्याप्त देखभाल करते हैं।

अवास्तविक छोड़ने के कारणों में से एक यह है कि इंजन मुख्य रूप से ब्लूप्रिंट/फ्रंट एंड गेम निर्माण के लिए तैयार किया गया है। सी ++ मॉड्यूल में टूलिंग बनाना अवास्तविक में बेहद दर्दनाक और जटिल है।

अब तक, गोडोट में यह शालीनता से सुखद रहा है। C++ का निर्माण तेजी से करना समुदाय के लिए एक बड़ा प्लस होगा।

IIRC वे MSVC बिल्ड टूल्स को चलाने के लिए वाइन का उपयोग करते हैं। अभी भी आपकी बात नहीं बदली है, और मैं सहमत हूँ।

केवल Linux पर निर्माण करना बेकार है। एक गेम इंजन जो विंडोज़ पर नहीं चलता है, किसी भी गंभीर गेम डेवलपर्स को रोक देगा।

सिर्फ लिनक्स ही नहीं, गोडोट हमेशा कई प्लेटफॉर्म पर बिल्ड करने योग्य रहा है...

IIRC वे MSVC बिल्ड टूल्स को चलाने के लिए वाइन का उपयोग करते हैं। अभी भी आपकी बात नहीं बदली है, और मैं सहमत हूँ।

आधिकारिक विंडोज़ बिल्ड मिनजीडब्ल्यू का उपयोग करके संकलित किए गए हैं; हम Linux पर MSVC चलाने के लिए WINE का उपयोग नहीं करते हैं।

@marstaik - यदि आप MSVS प्रोजेक्ट फ़ाइलों को उत्पन्न करने के लिए बिल्ड और रन

इसलिए कोशिश करें:

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

स्कैन पूरी तरह से निर्माण किए बिना ऐसा करने में सक्षम होना चाहिए और इसे पहले साफ करने की आवश्यकता के बिना इसे सही तरीके से करना चाहिए।
(BTW। मैं स्कैन्स प्रोजेक्ट मेंटेनर हूं)

@bdbaddog मुझे उस कमांड में vsproj=True जोड़ना था, लेकिन ऐसा लगता है कि यह काम कर गया है

गोडोट स्रोत से:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

संपादित करें: किसी कारण से आपको -j ध्वज भी जोड़ना होगा ...

@bdbaddog मुझे उस कमांड में vsproj=True जोड़ना था, लेकिन ऐसा लगता है कि यह काम कर गया है

गोडोट स्रोत से:
scons -j24 godot.vxcproj num_jobs=x vsproj=true

संपादित करें: किसी कारण से आपको -j ध्वज भी जोड़ना होगा ...

इस तरह के बहुत से झंडे वैनिला स्कैन नहीं हैं, लेकिन विभिन्न पैकेज (इस मामले में गोडोट) स्कैन के साथ अपने निर्माण प्रणाली को लागू करने के तरीके का हिस्सा हैं।
खुशी है कि आपको एक रास्ता मिल गया!

स्कैनस्ट्रक्चर का उपयोग क्यों करें और अन्य बिल्ड सिस्टम पर स्विच न करने पर जोर दें ???

@tjysdsg ऊपर की चर्चा बहुत अच्छी तरह से बताती है:

मैं इसे बंद कर दूंगा क्योंकि हमने वर्षों से यह स्पष्ट कर दिया है कि बिल्ड सिस्टम को बदलने की हमारी कोई प्राथमिकता नहीं है। हम SCons से खुश हैं और इसकी किसी भी कमियों का मूल्यांकन व्यक्तिगत रूप से किया जाना चाहिए, हमारे अपने SCons उपयोग और अपस्ट्रीम दोनों में, यदि यह टूलिंग के कारण ही है।

इसके लिए "कूलर" बिल्ड सिस्टम पर स्विच करने से ऐसा नहीं होगा। मुख्य योगदानकर्ताओं का विशाल बहुमत स्कैन का उपयोग करके खुश है और यह वह है जिसे अब हम सबसे अच्छी तरह जानते हैं। एक नए बिल्ड सिस्टम पर स्विच करने में कार्यान्वयन और सीखने की लागत दोनों होती है, और यह अब तक साबित नहीं हुआ है कि वे परेशानी के लायक होंगे।

कुल मिलाकर, एक बिल्डसिस्टम परिवर्तन कुछ ऐसा नहीं है जिसे हम नए योगदानकर्ताओं से स्वीकार करेंगे। इसे अंदर से आना होगा, और सभी मुख्य योगदानकर्ताओं को इसे एक सकारात्मक बदलाव के रूप में देखना चाहिए ताकि इसका कोई अर्थ निकल सके। हम केवल नए उपयोगकर्ताओं को खुश करने के लिए बिल्ड सिस्टम को नहीं बदलेंगे जो स्रोत से गोडोट बनाने का प्रयास करते हैं और किसी तरह यह पसंद नहीं करते cmake या meson बजाय scons टाइप करना होगा meson जिसका वे उपयोग करते हैं। हम एक वैकल्पिक नए बिल्ड सिस्टम को पेश करने के प्रयासों को भी स्वीकार नहीं करेंगे - अनुभव से, मुझे पता है कि इससे केवल असंगतता, बग और आउटपुट अंतर हो सकते हैं।

निश्चित रूप से हम अपने दिमाग को बदलने के लिए खुले हैं यदि स्पष्ट लाभ सूचीबद्ध किया जा सकता है (और अवधारणा के एक कामकाजी सबूत के साथ दिखाया गया है) जो कि बिल्ड सिस्टम को बदलने की लागत से अधिक है, लेकिन आज के रूप में और यहां दो साल की चर्चा के बाद, मैं व्यक्तिगत रूप से डॉन प्रोत्साहन नहीं देखा।

@ स्लर्प्स-मैड-रिप्स ने इसे अच्छी तरह से कहा।

यह जटिल है क्योंकि यह स्कैन का उपयोग करता है।

तथा

मेरा सीएमके बिल्ड स्थिर विश्लेषण त्रुटियों का एक समूह पकड़ने में सक्षम था जिसके कारण कई समस्याएं हुई हैं और आसानी से हल हो सकती हैं

यह घृणित है कि सीएमके पर गंभीरता से विचार नहीं किया गया है, मैं स्कैन को छोड़ने के कई कारणों के बारे में सोच सकता हूं, लेकिन विशेष रूप से सीएमके को त्रुटियां मिलती हैं स्कैन्स को यह कुछ और उपयोग करने के लिए "इसके लायक" बनाता है।

इसके लिए "कूलर" बिल्ड सिस्टम पर स्विच करने से ऐसा नहीं होगा

सीएमके "कूलर" नहीं है, यह मानक है। यदि आप वास्तव में इसका इस्तेमाल करते हैं तो आप तुरंत समझ जाएंगे कि क्यों।

निश्चित रूप से हम अपने दिमाग को बदलने के लिए खुले हैं यदि स्पष्ट लाभ सूचीबद्ध किया जा सकता है (और अवधारणा के कामकाजी प्रमाण के साथ दिखाया गया है) जो कि बिल्ड सिस्टम को बदलने की लागत से अधिक है

मुझे विश्वास नहीं है कि कोई भी अपना विचार बदलने के लिए तैयार है। फिर से, @ slurps-mad-rips ने स्पष्ट लाभ दिखाया, और उसने सारा काम भी किया ... यह पहले ही हो चुका है।

यह शर्मनाक है, गोडोट टीम के आधिकारिक रुख का प्रतिनिधित्व करते हुए, विकास प्रक्रिया में सुधार के उसके प्रयासों की पूरी तरह से अवहेलना करना।

मैं आपके दर्द को अच्छी तरह समझता हूं लेकिन मैं अभी भी दूसरों से सहमत हूं - सभी बिल्ड
सिस्टम उनके हैं
पेशेवरों और विपक्ष और आम तौर पर वही। शायद ही कोई तकनीकी कारण हो
इसे बदलने के लिए।
राजनीतिक कारणों से वे लंबे समय तक आपका कुछ भी अच्छा नहीं करेंगे
Daud। हर
कुछ अलग पसंद करते हैं। वैसे भी किसी को फोर्क करने से कोई नहीं रोकता
सबकुछ के लिए
कारण, इसलिए मुझे लगता है कि यह उतना ही अच्छा है जितना कोई।

शुक्र, 21 फरवरी, 2020 को दोपहर 1:38 बजे डॉर्कबॉक्स नोटिफिकेशन @github.com ने लिखा:

@ slurps-mad-rips https://github.com/slurps-mad-rips ने इसे अच्छी तरह से कहा।

यह जटिल है क्योंकि यह स्कैन का उपयोग करता है।

तथा

मेरा सीएमके बिल्ड स्थिर विश्लेषण त्रुटियों का एक समूह पकड़ने में सक्षम था कि
कई मुद्दों को जन्म दिया है और आसानी से हल किया जा सकता है

यह घृणित है कि सीएमके पर गंभीरता से विचार नहीं किया जाता है, मैं कर सकता हूं
स्कैन को छोड़ने के कई कारणों के बारे में सोचें, लेकिन विशेष रूप से सीएमके को पता चलता है
एरर स्कैन्स को नहीं मिलता है, यह कुछ और उपयोग करने के लिए "इसके लायक" बनाता है।

इसके लिए "कूलर" बिल्ड सिस्टम पर स्विच करने से ऐसा नहीं होगा

सीएमके "कूलर" नहीं है, यह मानक है। यदि आप वास्तव में इसका इस्तेमाल करते हैं तो आप करेंगे
तुरंत समझें क्यों।

यदि स्पष्ट लाभों को सूचीबद्ध किया जा सकता है, तो निश्चित रूप से हम अपने विचार बदलने के लिए तैयार हैं
(और अवधारणा के एक कार्यशील प्रमाण के साथ दिखाया गया है) जो की लागत से अधिक है
बिल्डसिस्टम को बदलना

मुझे विश्वास नहीं है कि कोई भी अपना विचार बदलने के लिए तैयार है। फिर से,
@ slurps-mad-rips https://github.com/slurps-mad-rips ने स्पष्ट लाभ दिखाया,
और उसने सारा काम भी किया... यह पहले ही हो चुका है।

यह शर्मनाक है, गोडोट टीम के आधिकारिक रुख का प्रतिनिधित्व करते हुए, to
विकास प्रक्रिया में सुधार के उनके प्रयासों की पूरी तरह से अवहेलना करें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU2PBIEK6PFKQ2LDTHLRD6VKVA5CNFSM4ENJ6NN2YY3PNVWWWK3TUL52HS4DFVREXGEMSIVMVBW63LNMVWS89Y8247KT
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAABPU746R4YFHAI73Z57RTRD6VKVANCNFSM4ENJ6NNQ
.

@dorkbox - सेमेक को स्थिर विश्लेषण त्रुटियां मिलीं? या यह llvm के स्थिर विश्लेषण उपकरण के माध्यम से cmake रन से संकलन डेटाबेस आउटपुट था जो उन्हें मिला?

@bdbaddog , @ slurps-mad-rips ने इस पर काम किया, और उससे पूछना सबसे अच्छा होगा। (मुझे लगता है कि यह एलवीएम के स्थिर विश्लेषण से आउटपुट होगा, लेकिन मैं वह नहीं हूं जिसने सेमेक के माध्यम से निर्माण करने का काम किया है)

@slapin

इसे बदलने का शायद ही कोई तकनीकी कारण हो।

स्थैतिक विश्लेषण उपकरण और आधुनिक भाषा सुविधाओं के बारे में कैसे समर्थन करते हैं?

@bdbaddog @dorkbox मैंने सीएमके के माध्यम से "गैर स्थैतिक स्थानीय लोगों के संदर्भ लौटने" और "बफर ओवरफ्लो" जैसी चीजों को देखने के लिए बस include-what-you-use प्राप्त करने में सक्षम था, और इसमें कुछ अनावश्यक शीर्षलेख समावेशन पाए गए।

उस ने कहा, मैंने वास्तव में सेमेक पोर्ट को "खत्म" नहीं किया था। वह हिस्सा जिसे कभी पोर्ट नहीं किया गया था, वह सभी काम था जो मैंने वर्तमान पायथन लिपियों को बदलने की कोशिश के साथ किया था जो कि JSON से फ़ाइल बनाने के लिए किसी फ़ाइल पर f.write पर कॉल करते हैं। मैं उस तर्क को हटाने में सक्षम था और इसे एक सामान्य जिन्जा 2 आधारित टेम्पलेट जनरेटर से बदल दिया। इसने एक हैक को भी हल किया जो वर्तमान स्कैन बिल्ड विंडोज़ पर करता है जहां यह एक निष्पादन योग्य के रूप में एक स्क्रिप्ट लॉन्च करता है।

हालाँकि मैंने स्कैन बिल्ड के साथ समानता बनाए रखने की उम्मीद की थी और बहुत कम से कम कोड जनरेशन में मेरे परिवर्तन मर्ज किए गए थे। ऐसा नहीं हुआ क्योंकि स्रोत फ़ाइलों को उत्पन्न करने के लिए उपयोग की जाने वाली पायथन स्क्रिप्ट लगातार बदल रही हैं, और उन परिवर्तनों को सिंक में रखते हुए मेरे jinja2 टेम्पलेट के साथ निराशा में एक अभ्यास था।

जीडीसी गिटहब मीटअप में प्रमुख डेवलपर्स से मुझे बहुत जोरदार और कठिन "नहीं" मिला, मैंने फैसला किया कि मैं अब गोडोट में योगदान नहीं देना चाहता हूं। मेरे परिवर्तन अवांछित थे, वांछित नहीं हैं, और वे इस मामले पर किसी और की राय के प्रति उदासीन हैं। मैं गोडोट में योगदान नहीं दूंगा, न ही गोडोट के किसी कांटे में। मैं इस मामले में प्रमुख देवों को समझाने की कोशिश में आप सभी को शुभकामनाएं देता हूं लेकिन यह एक ईंट की दीवार से बात करने जैसा है। इस सूत्र में सभी की दुर्दशा के प्रति अडिग, अचल और उदासीन।

तो अगर स्कैन्स संकलन डेटाबेस को थूक सकते हैं जो llvm टूल्स में इनपुट है तो यह स्कैन से भी किया जा सकेगा।

तो अगर स्कैन्स संकलन डेटाबेस को थूक सकते हैं जो llvm टूल्स में इनपुट है तो यह स्कैन से भी किया जा सकेगा।

ऐसा लगता है कि स्कैन्स के साथ डूब-लागत की गिरावट चल रही है। कुछ आसान, सुव्यवस्थित, और पहले से ही मौजूदा बिल्ड टूल्स का हिस्सा, जैसे सेमेक का उपयोग क्यों न करें?

स्कैन वेबसाइट से:

स्कैन की तुलना में, सीएमके है:

• और तेज
• सामान्य कार्यों के लिए कम कोड की आवश्यकता होती है
  
  
  
  • यकीनन अधिक स्थिर
  
  
  • कोड :: ब्लॉक, एक्सकोड इत्यादि जैसी परियोजनाओं को आउटपुट का समर्थन करता है जो स्कैन नहीं करता है
  
  

@dorkbox - मैं

पिछली कुछ रिलीज़ और आगामी रिलीज़ में प्रदर्शन में सुधार हुआ है।

इसके अतिरिक्त हमारे पास निंजा फ़ाइल निर्माण के लिए पीआर हैं और कुछ समुदाय के सदस्यों के पास संकलन डेटाबेस उपकरण हैं। तो कुछ मुद्दों को अगली रिलीज में संबोधित किए जाने की संभावना है (कम से कम आंशिक रूप से, यदि पूरी तरह से नहीं)।

मुझे गोडोट परियोजना को प्रभावित करने वाले किसी भी स्थिरता के मुद्दों के बारे में पता नहीं है जिसे हमने संबोधित नहीं किया है। यदि कोई बकाया है तो कृपया हमें बताएं।
(हमसे संपर्क करें: https://scons.org/contact.html)

मुझे यकीन नहीं है कि सेमेक को वास्तव में सामान्य कार्यों के लिए कम कोड की आवश्यकता है, मुझे उचित तुलना में दिलचस्पी होगी।

खैर, जो चीज मुझे सबसे ज्यादा परेशान करती है, वह है सादे पुराने को उत्पन्न करने में असमर्थता
जीएनयू मेकफ़ाइल बनाते हैं। निंजा की कमी - मैं इसके साथ रह सकता हूं।
सीएमके टूलचेन और ऑटोटूल जैसी क्रॉस-कंपाइल उपयोगिता को भी संभालना
क्रॉस-कंपाइलिंग क्षमताएं मजबूत हैं cmake कमजोर बिंदु।
बाकी ठीक है क्योंकि मैं आईडीई व्यक्ति नहीं हूं। मेरा आईडीई यूनिक्स पर्यावरण है।

रविवार 23 फरवरी, 2020 को रात 10:05 बजे विलियम डीगन नोटिफिकेशन @github.com
लिखा था:

@dorkbox https://github.com/dorkbox - मैं स्कैन प्रोजेक्ट का सह-प्रबंधक हूं।
मैं सिर्फ वांछित कार्यक्षमता पर नजर रख रहा हूं।

पिछली कुछ रिलीज़ और आने वाली रिलीज़ का प्रदर्शन अच्छा रहा है
सुधार।

इसके अतिरिक्त हमारे पास निंजा फ़ाइल निर्माण और कुछ समुदाय के लिए पीआर हैं
सदस्यों के पास संकलन डेटाबेस उपकरण हैं। तो कुछ मुद्दों की संभावना है
अगली रिलीज में (कम से कम आंशिक रूप से, यदि पूरी तरह से नहीं) संबोधित किया जाना है।

मुझे गोडोट परियोजना को प्रभावित करने वाले किसी भी स्थिरता के मुद्दों के बारे में पता नहीं है जो हम
संबोधित नहीं किया है। यदि कोई बकाया है तो कृपया हमें बताएं।
(हमसे संपर्क करें: https://scons.org/contact.html)

मुझे यकीन नहीं है कि सेमेक को आम कार्यों के लिए वास्तव में कम कोड की आवश्यकता है, मैं होगा
उचित तुलना में रुचि।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/16014?email_source=notifications&email_token=AAABPU5TQQFET5RS2JDRY7TRELCHDA5CNFSM4ENJ6NN2YY3PNVWWWK3TUL52HS4DFVREXG43VMVBW63LNMV10W2GOMIWS मुद्दा
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAABPU6UHpx3HJTWPAFTPATRELCHDANCNFSM4ENJ6NNQ
.