Lapack: सिस्टम बनाएं

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

सीएमके वर्तमान में बनाता है (प्रतीत होता है) पुस्तकालय के केवल चुनिंदा हिस्सों (वास्तविक, डबल, कॉम्प्लेक्स और/या डबल कॉम्प्लेक्स) बनाने के विकल्प का समर्थन करता है।

पिछली बार जब मैंने इसे आजमाया था तो इस विकल्प ने काम किया था (मई 2020 के आसपास)।

सीएमके बिल्ड में कई विकल्प हैं, मैं यहां मेरे लिए सबसे महत्वपूर्ण सूची देता हूं:

• साझा या स्थिर पुस्तकालयों का निर्माण
• सक्षम या अक्षम परीक्षण
• 64- या 32-बिट सूचकांक
• अनुकूलित और डिबगिंग बनाता है
• मैट्रिक्स जनरेटर लाइब्रेरी (TMG) के लिए विकल्प, अन्य BLAS पुस्तकालयों का उपयोग, BLAS++, LAPACK++...

अच्छा विचार। मेक के साथ मेरी मशीन पर काम करता है लेकिन सीएमके के साथ सीआई पर नहीं, मुझे कुछ बार पागल कर दिया है।

तकनीकी रूप से, मुझे लगता है कि मेकफ़ाइल भी उन विकल्पों में से बहुत से समर्थन करता है (आप बस अपना make.inc संपादित कर सकते हैं)। यदि आप परीक्षणों के बिना निर्माण चाहते हैं तो आप make lib साथ निर्माण कर सकते हैं। लेकिन महत्वपूर्ण बात यह है कि साझा पुस्तकालय का निर्माण समर्थित नहीं है। अधिकांश लोग LAPACK को साझा पुस्तकालय के रूप में उपयोग करते हैं जिससे सीएमके मेरे लिए स्पष्ट विजेता बन जाता है।

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

मुझे संदेह है कि जीएमके के साथ साझा पुस्तकालयों का निर्माण करने के लिए पहले से ही कई पैच तैर रहे होंगे (उदाहरण के लिए पैकेज लैपैक लिनक्स वितरण में)। बनाने के लिए BUILD_SHARED विकल्प जोड़ने के लिए बहुत जटिल नहीं होना चाहिए। BUILD_DEPRECATED की तरह जो पहले से मौजूद है (और दोनों सीएमके बिल्ड में बहुत अस्पष्ट हैं जब तक कि कोई पहले से ही नहीं जानता कि सीसीमेक और सेमेक-गुई मौजूद है)।

बनाने के लिए BUILD_SHARED विकल्प जोड़ने के लिए बहुत जटिल नहीं होना चाहिए। BUILD_DEPRECATED की तरह जो पहले से मौजूद है (और दोनों सीएमके बिल्ड में बहुत अस्पष्ट हैं जब तक कि कोई पहले से ही नहीं जानता कि सीसीमेक और सेमेक-गुई मौजूद है)।

इनमें से किसी भी विकल्प को सेट करने के लिए ccmake साथ काम करने की कोई आवश्यकता नहीं है। आप ऑटोटूलस द्वारा उत्पन्न configure स्क्रिप्ट के समान कमांड लाइन का उपयोग कर सकते हैं:

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

आप निश्चित रूप से कर सकते हैं, मेरी बात यह है कि CMakelists.txt को पढ़ने के अलावा कोई स्पष्ट दस्तावेज नहीं है (जबकि रीडमे एक को पूर्व-कॉन्फ़िगर किए गए make.inc फ़ाइलों को gmake के लिए इंगित करता है)। ccmake और cmake-gui उपलब्ध विकल्पों की एक सूची दिखाते हैं, लेकिन यह cmake के लिए नए किसी भी व्यक्ति पर खो जाएगा।

यदि हम CMAKE का उपयोग करने के बारे में एक दस्तावेज लिखते हैं, तो हम मुझे गिनी पिग उपयोगकर्ता के रूप में उपयोग कर सकते हैं क्योंकि मैंने कभी CMAKE का उपयोग नहीं किया है।

पूरी बातचीत को पढ़कर, मुझे लगता है कि मेकफ़ाइल LAPACK में केवल मेरे लिए है। ;)

वैसे मुझे पता नहीं है।

हां: कई बिल्ड सिस्टम को बनाए रखने से विसंगतियां होती हैं। तो मैं केवल एक के लिए तर्क देखता हूं। (चाहे वह सीएमकेई हो, मेक या मेसन।) (ओह हाँ, मैंने कभी मेसन का इस्तेमाल नहीं किया है, अगर आप आश्चर्य करते हैं।)

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

सभी: कृपया इस सूत्र में अपनी राय व्यक्त करें।

ऐसा लगता है कि हममें से अधिकांश लोग (1) मेसन बनाना और हटाना चाहते हैं; (2) केवल CMAKE पर जाएँ; (3) सीएमकेई का उपयोग कैसे करें, इस पर कुछ अच्छे दस्तावेज जोड़ें। मेरे लिए उत्तम है।

मैं यहां और वहां अन्य पैकेज अनुरक्षकों को कुछ ईमेल भेजने जा रहा हूं ताकि यह पूछा जा सके कि वे कैसे कर रहे हैं और इस मुद्दे पर उनकी क्या राय है।

@ मार्टिन-एफआरबीजी: ओपनबीएलएएस में यह कैसे किया जाता है?

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

मैं मेसन समर्थन के इतिहास को नहीं जानता - अगर यह एक बार "बाड़ पर फेंका गया" योगदान था जिसे कोई भी नहीं जानता या अद्यतन रखने के लिए पर्याप्त परवाह नहीं करता है, तो मुझे लगता है कि इसे आसपास रखने का कोई मतलब नहीं है।

मेसन बिल्ड को पीआर #311 में LAPACK में पैराशूट किया गया था।

हम्म। अगर इसे 3.9.0 में स्वीकार कर लिया गया (भले ही अवधारणा के प्रमाण के रूप में), तो अगली रिलीज के साथ इसे फिर से फेंकना थोड़ा अजीब लगेगा ...

मैंने @therault से संपर्क @therault का कहना है। धन्यवाद @therault!

ओपन एमपीआई केवल ऑटोकॉन्फ़ (ऑटोमेक, ऑटोकॉन्फ़, कॉन्फ़िगर, मेकफ़ाइल) का उपयोग करता है।

PaRSEC और DPLASMA के लिए, हम केवल CMake का उपयोग करते हैं, और उन उपयोगकर्ताओं की मदद करने के लिए जो कॉन्फ़िगर करने के लिए उपयोग किए जाते हैं, @abouteiller ने एक स्क्रिप्ट बनाई जो कॉन्फ़िगरेशन के सिंटैक्स का उपयोग करती है और CMake को अपने सिंटैक्स के साथ कॉल करती है।

मुझे एक प्रमुख परियोजना के बारे में पता है जिसने कॉन्फ़िगर और सीएमके दोनों को बनाए रखने की कोशिश की। यह धीरे-धीरे ऐसी स्थिति में विकसित हुआ जहां सीएमके में 100% सुविधाएं उपलब्ध थीं, और कम और कम नई सुविधाओं को कॉन्फ़िगर में समर्थित किया गया था। मेरा मानना ​​है कि उन्होंने कॉन्फ़िगरेशन संस्करण को बनाए रखना बंद कर दिया है।

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

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

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

मुझे LAPACK को कॉन्फिगर-टू-सेमेक ग्लू स्क्रिप्ट में योगदान करने में खुशी हो रही है, अगर ऐसा कुछ है जिसमें आप रुचि रखते हैं।
(स्पष्ट करने के लिए, वह स्क्रिप्ट autoconf/m4 आधारित नहीं है, यह एक साधारण स्क्रिप्ट है जो configure --with-feature=value को कॉल में परिवर्तित करती है cmake -DFEATURE=value , थोड़ी अधिक पॉलिश के साथ)।

LAPACK कॉन्फ़िगर का उपयोग भी नहीं करता है - और मैं मानता हूं कि यह संभवतः एक ऑटोकॉन्फ़/ऑटोमेक/कॉन्फ़िगर-आधारित सिस्टम को सेमेक के साथ समवर्ती रखने के लिए दर्द होगा, ऑटोटूल स्वयं लगातार "विकसित" और एम 4 मैक्रोज़ और व्हाट्नॉट पर निर्भर होने के साथ।

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

Makefiles से चिपके रहने का यह एक प्रमुख कारण है।

सभी: कृपया इस सूत्र में अपनी राय व्यक्त करें।

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

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

मैंने पहली बार 2016 में सीएमके का इस्तेमाल किया था और तब से मैंने इसे लगातार लिनक्स, मैक, आईओएस और एंड्रॉइड सिस्टम के लिए x86, x86-64, armv7 और aarch64 इंस्ट्रक्शन सेट आर्किटेक्चर पर कोड बनाने के लिए इस्तेमाल किया है। यह सभी प्रमुख लिनक्स वितरणों और उन सभी सुपर कंप्यूटरों पर उपलब्ध है, जिन तक मेरी पहुंच है (ग्रिड 5000, जीन ज़ाय, ज्यूवेल्स, ग्रिकैड, ईगल II)। सुपरकंप्यूटर में आमतौर पर पुराने रिलीज़ और बहुत हाल के संस्करण (3.18+) सहित कई संस्करण उपलब्ध होते हैं। एकमात्र मंच जहां मैंने सीएमके की उपलब्धता के साथ संघर्ष किया, वह सेंटोस 7 है, लेकिन आप हमेशा सीएमके टारबॉल डाउनलोड कर सकते हैं और टारबॉल के अंदर बूटस्ट्रैप स्क्रिप्ट का उपयोग करके सीएमके को केवल जीएनयू मेक के साथ बना सकते हैं।

सीएमके सिर्फ मेरे लिए काम करता है।

अन्य बिल्ड सिस्टम के साथ मेरा अनुभव इस प्रकार है:

• बेज़ेल: एक विशाल मेमोरी हॉग, 1GB मेमोरी के साथ रास्पबेरी पाई पर चलाना असंभव है, सभी निर्भरताओं को बनाने पर जोर देता है, और सब कुछ स्थिर रूप से लिंक करता है
• Autotools: एक डेवलपर कोई अनुभव नहीं, एक उपयोगकर्ता के रूप के रूप में configure स्क्रिप्ट बहुत सुविधाजनक है, क्योंकि यह आप सभी उपलब्ध विकल्पों में दिखा सकते हैं (CMake करता है उस के साथ ccmake केवल चलाने के बाद cmake एक बार)।

आज, मैं एक ही कारण से सीएमके के पक्ष में हूं: सीएमके मेकफाइल्स के बजाय निंजा फाइलें बनाने में अच्छा काम करता है। निंजा मेक-जे की तुलना में दो बार से तीन गुना तेजी से पारसेक को संकलित करता है।

बढ़िया, निंजा अतीत में फोरट्रान संकलित नहीं कर सका, सीएफ। निन्जा #1265 , यानी, कुछ वितरणों पर यह काम नहीं करेगा (डेबियन 9?)।

मैं निश्चित रूप से कहूंगा कि इस मामले में नियमित मेकफ़ाइल आसान और पर्याप्त हैं।
एचपीसी क्लस्टर में सॉफ्टवेयर बनाए रखना मैं सेमेक के उपयोग से बहुत निराश हूं।

1. डेवलपर्स को मानक नामकरण योजनाओं का पालन करने में कठिनाई होती है, जिससे अत्यधिक दस्तावेज़ पढ़ने के कारण कठिन समय का निर्माण होता है। प्रत्येक पैकेज नामों में से कुछ "ट्वीक" करता है जो उनकी परियोजनाओं में फिट बैठता है। इस प्रकार गैर-मानक नामकरण योजनाओं में समाप्त हो रहा है। (ऑटोकॉन्फ़ + के लिए थोड़ा सा सच है, लेकिन यहाँ चीजें अधिक मानकीकृत हैं)
2. जब सेमेक में सामान टूट जाता है, तो इसे डिबग करने के लिए एक सेमेक विशेषज्ञ की आवश्यकता होती है, मेरे पास अभी भी बहुत कठिन समय डिबगिंग सामान है ... :(
3. कॉन्फ़िगरेशन फ़ाइलों का उपयोग करना कठिन है (नहीं make.inc ), यह सभी बिल्ड-विकल्पों को बिल्ड-टाइम पर कमांड-लाइन पर निर्दिष्ट करने के लिए मजबूर करता है।

दूसरी ओर, सेमेक भी अच्छी चीजें करता है:

1. आसान विंडोज़ सपोर्ट
2. निर्भरता की अधिक स्वचालित हैंडलिंग और अन्य परियोजनाओं के लिए cmake फ़ाइलों को शामिल करना (यह एक अच्छा लाभ है)

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

मेरे पास वास्तव में वरीयता नहीं है, लेकिन यह बिल्कुल स्पष्ट होना चाहिए

मुझे लगता है कि मेरी भी वैसी ही स्थिति है जैसे आप @langou हैं ।

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

हालांकि, मैं cmake की पेशकश की सभी अच्छी सुविधाओं को अनदेखा नहीं कर सकता। आखिरकार, मुझे लगता है कि या तो सेमेक या जीएमके ठीक करेगा। हमें बस एक को चुनना है।

मैं एक बाहरी आवाज हूं, लेकिन किसी ऐसे व्यक्ति के रूप में जो लैपैक को कोंडा-फोर्ज में बनाए रखने में मदद करता है, बिल्ड सिस्टम हैकी , देशी विंडोज़ समर्थन, आदि)।

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

बाहर से बस एक और डेटा बिंदु; हमारे काम में जिसमें काफी सी/सी ++ बिल्डिंग शामिल है, हम सीएमके के साथ बहुत अधिक संघर्ष करने के बाद मेसन जा रहे हैं। इसके साथ मुद्दों की लंबी सूची कहीं और अच्छी तरह से प्रलेखित है इसलिए मैं उन्हें छोड़ रहा हूं।

SciPy प्रोजेक्ट में हम किसी बिंदु पर सीएमके या मेसन का उपयोग करने का भी प्रयास करेंगे क्योंकि पायथन distutils को निष्क्रिय किया जा रहा है।

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

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

एकाधिक बिल्ड सिस्टम के साथ समस्या को दूर करने का एक विचार है:

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

जहां तक ​​मैं समझता हूं, recursive ध्वज के साथ मुद्दा परीक्षण दिनचर्या xeigtstz (देखें https://github.com/Reference-LAPACK/lapack/issues/335# निर्गम टिप्पणी-485021575)। जब यह मुद्दा तय हो जाएगा, तो मेरी राय है कि हम दोनों में से किसी एक का फैसला करेंगे

1. ध्वज को डिफ़ॉल्ट सीएमके कॉन्फ़िगरेशन में जोड़ें और जहां कहीं भी यह गायब है, या
2. make.inc.* फ़ाइलों से ध्वज हटा दें।

थोड़ी सी गलतफहमी wrt -frecursive मुझे लगता है - यह मल्टीथ्रेडेड कोड के सही कामकाज के लिए आवश्यक है, इसलिए इसे सामान्य रूप से बिल्ड फाइलों से नहीं हटाया जाना चाहिए। हालांकि, एक साइड इफेक्ट यह है कि यह स्थानीय सरणियों को स्टैक पर रखता है, जो कि xeigtstz मामले में बहुत बड़ा होता है। इस विकल्प को (केवल) टेस्टिंग/ईआईजी मेकफ़ाइल से हटाने से साधारण मामले में मदद मिलती है, लेकिन ऐसा लगता है कि यह '-fopenmp' के साथ संकलित करते समय निहित है, इसलिए यह उस परीक्षण की असामान्य रूप से बड़ी स्टैकलिमिट आवश्यकताओं के लिए कोई सामान्य समाधान नहीं है।

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

तो अगर हमें एक बिल्ड सिस्टम चुनना है: यह सेमेक होना चाहिए ... दुर्भाग्य से वर्तमान के लिए लेकिन सौभाग्य से भविष्य के लिए।

मेरा वोट: @abouteiller और @ @therault की सलाह के बाद और केवल एक बिल्ड सिस्टम है, इस प्रकार cmake।

अब LAPACK पर आधारित अधिकांश सॉफ्टवेयर Cmake का उपयोग कर रहे हैं और हम अपने उपयोगकर्ता फीडबैक से जानते हैं, वे इसे पसंद करते हैं।

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

(नियमित योगदानकर्ता कौन है, इस बारे में मेरा निर्णय स्वीकृत पुल अनुरोधों के पहले पांच पृष्ठों को देखने पर आधारित है।)

सहमत .. बीटीडब्ल्यू, रिकर्सिव झंडे डिफ़ॉल्ट सीएमके और मेकफ़ाइल कॉन्फ़िगरेशन में # 492 के साथ हैं। तो, मुझे लगता है कि हमें केवल ट्रैविस सीआई में मेकफ़ाइल बिल्ड को शामिल करने की आवश्यकता है।

पीआर #500 यहां रिपोर्ट की गई मेकफ़ाइल और सीएमके बिल्ड सिस्टम के बीच विसंगतियों को कम करता है। देखें https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

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