Occa: सेमेक समर्थन

मेरे 2 सेंट...

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

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

हाय पॉल,

मैं इसके साथ प्यार में नहीं हूँ, लेकिन एक बार एक परियोजना में स्थापित होने के बाद यह बहुत ठोस है। इसका प्रमुख लाभ एकीकरण और परीक्षण है। उदाहरण के लिए - मान लीजिए - मैं ओसीसीए को एक बड़े कोड में एकीकृत करना शुरू कर दूंगा, मैं स्रोत को तृतीय पक्ष नामक निर्देशिका में डाल दूंगा, और, यदि यह सेमेक का उपयोग कर रहा था तो मैं केवल नई निर्देशिका add_directory (...) के cmake को बताऊंगा। . फिर यह "शीर्ष" CMakeLists.txt से कंपाइलर्स और अन्य स्पेक्स का उपयोग करके स्वचालित रूप से ओसीसीए का निर्माण करेगा। अगर मैंने एक परीक्षण चालक (शुरू में) और बाद में अधिक स्रोत/अन्य निर्देशिकाओं में ओसीसीए पर निर्भरता जोड़ दी तो यह एक हवा होगी।

सेमेक के साथ मेरा अनुभव यह है कि यदि आपको "मेक" स्तर पर समस्याएं हैं, तो आमतौर पर समस्या यह है कि आपने शीर्ष स्तर पर बहुत अधिक विशेषज्ञता प्राप्त की है (उदाहरण के लिए स्पष्ट संकलक झंडे ...) सेमेक। अधिकांश समस्याओं के लिए VERBOSE=1 पूर्ण संकलन लाइन (जिसे आप कट और पेस्ट कर सकते हैं) को यह पता लगाने के लिए प्रकट करेंगे कि क्या गलत है (और फिर सेमेक बदलें (मेक नहीं))।

हम भी हर समय ctest का उपयोग करते हैं...

किसी भी तरह, बस इस संबंध में पानी का परीक्षण करना चाहता था।

श्रेष्ठ,

अमीकी

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

@henryiii अगर इसमें आईडीई एकीकरण है, तो यह एक अच्छा विचार है!

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

यदि आपके पास समय है, तो क्या आप इसके लिए कोर सीएमके फाइलों के साथ पीआर बना सकते हैं? अगर यह मदद करता है, तो मैं निर्माण समय के दौरान अपेक्षित सभी पर्यावरण चर/दुष्प्रभावों को जोड़ सकता हूं

अभी, नए/संभावित ओसीसीए उपयोगकर्ताओं (एचपीसी प्रोग्रामर) को केवल ओसीसीए स्रोत डाउनलोड करने की जरूरत है, और make टाइप करें। बहुत सरल। मेरे लिए, ओसीसीए मूल्य प्रस्ताव समानांतर प्रोग्रामिंग डोमेन में प्रदान की जाने वाली उत्कृष्ट सुविधाओं पर 100% आधारित है, न कि इसकी बिल्ड सिस्टम में। फिर भी, शायद ओसीसीए के लिए सेमेक-आधारित बिल्ड में जाने के लिए एक छोटा मूल्य-वर्धित होगा, मुझे नहीं पता।

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

सेमेक के विषय पर वापस, हम में से कुछ के लिए वैसे भी, "लाभ भिन्न हो सकता है।" गंभीरता से, मुझे यकीन है कि सेमेक के लिए मेरा उत्साह बहुत बढ़ जाएगा यदि मैं वास्तव में सीखता हूं कि मेरे वर्तमान पूर्व-नौसिखिया चरण से परे एक स्तर पर सेमेक भाषा कोड कैसे लिखना/डीबग/संशोधित करना है। इस बीच, जब मुझे किसी के खराब लिखे / पुराने CMakeLists.txt और/या छोटी गाड़ी या खराब लिखी Find*.cmake फाइलों के साथ कुछ पैकेज के लिए ठीक से काम करने वाली निराशाजनक समस्याओं का सामना करना पड़ता है जिसे मैंने अभी डाउनलोड किया है मूल्यांकन के लिए जीथब, मुझे नकारात्मक प्रशंसा की अप्रिय संवेदना हो सकती है!

@pdhahn बस स्पष्ट होने के लिए, मुझे नहीं लगता कि मैं कभी भी "संकलन के लिए केवल make प्रकार" से छुटकारा पाऊंगा। निश्चित रूप से सफाई की आवश्यकता है (#149) लेकिन उपयोगकर्ताओं के लिए इंस्टॉलेशन और उपयोग को सरल बनाना यहां नंबर एक प्राथमिकता है

सीएमके को जोड़ने से उन परियोजनाओं में ओसीसीए का उपयोग करने में मदद मिलेगी जो पहले से ही सीएमके का उपयोग करते हैं और ऐसा लगता है कि इस आईडीई एकीकरण के साथ डेवलपर जीवन को आसान बना देता है।

@ dmed256 आप सही कह रहे हैं, IDE की बात ऐसी लगती है जैसे यह OCCA के लिए एक गैर-तुच्छ मूल्य जोड़ हो सकता है!

लेकिन आपको कम से कम कई लोकप्रिय आईडीई को समायोजित करने की आवश्यकता है, जैसे ग्रहण और क्यूटी निर्माता।

सीएमके केवल आईडीई ही नहीं, सभी प्रकार के उपकरणों का समर्थन करता है (और सभी प्रकार के उपकरण इसका समर्थन करते हैं)। सभी प्रमुख आईडीई या तो सीएमके द्वारा समर्थित हैं या सीएमके उनका समर्थन करते हैं। CLion, Qt Creator, Eclipe, Xcode, और बहुत कुछ। यह लिंक-व्हाट-यू-यूज, शामिल-क्या-यू-यूज, क्लैंग-टिडी, सीसीएचई, विभिन्न परीक्षण एकीकरण, पैकेजिंग, और बहुत कुछ का भी समर्थन करता है।

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

मैं अगले कुछ हफ्तों में ओका का मूल्यांकन करने की उम्मीद कर रहा हूं, और फिर सीएमके समर्थन में मदद करने में सक्षम हो सकता हूं।

@henryiii यह समझ में आता है, हमारे पास केवल इतना समय है :) भले ही, सीएमके सलाह की सराहना करें!

@hknibbe2 , @SFrijters , @amikstcyr , और @JamesEggleton के सभी कार्यों के लिए समापन धन्यवाद