LLVM कम्पाइलर्स के निर्माण के लिए "ईंटों" का एक सेट है, और क्लैंग एक नया C ++ कंपाइलर है जो इस पर आधारित है। Gcc की तुलना में, यह तुलनीय कोड गुणवत्ता, अधिक मानव-पठनीय स्रोतों, के साथ तेज संकलन गति प्रदान करता है वे gcc की तरह क्रूर C- केवल विकास के दशकों तक नहीं चलते हैं।

इसके अलावा, Clang और llvm को BSD के तहत GCC के GPLv3 के विपरीत लाइसेंस दिया जाता है। संकलक निष्पादनयोग्य वितरित करते समय बीएसडी आपको स्रोत नहीं खोलने की अनुमति देता है।

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

अधिकांश llvm / clang डेवलपर्स इसे Linux / MacOS के तहत उपयोग करते हैं - और वहां इसकी असेंबली / इंस्टॉलेशन से कोई समस्या नहीं होती है, पथ पूरी तरह से ट्रोड है। लेकिन खिड़कियों के मामले में, स्थिति कुछ हद तक जटिल है - असेंबली के दौरान कई रेक को दरकिनार करने के बारे में, क्या क्लैंग और जीसीसी को बांधता है, और क्या कीड़े को रिलीज में तय करना होगा - बिल्ली के नीचे।

सभा

विंडोज़ के तहत llvm + क्लैंग बनाने के 2 मुख्य तरीके हैं:

सीएमके आपको विजुअल स्टूडियो के लिए एक समाधान उत्पन्न करने की अनुमति देता है। clang + llvm अभी भी जीसीसी घटकों पर निर्भर करता है (उदाहरण के लिए, एक मानक पुस्तकालय, लेकिन निर्भरता को समाप्त करने के लिए काम चल रहा है), इसलिए यहां तक ​​कि विज़ुअल स्टूडियो में क्लैंग के निर्माण में अभी भी यह निर्भरता होगी, और आपको क्लैंग, वीएस और जीसीसी के टुकड़ों का एक बेतहाशा शौक़ीन मिलेगा, जहां सब कुछ घटक समय के साथ बेतरतीब ढंग से संस्करण बदलेंगे। इसके अलावा, इस समय विज़ुअल स्टूडियो 2012 क्रैश हो रहा है जब अनुकूलन के साथ 3.2 क्लैंग का निर्माण हो रहा है - माइक्रोसॉफ्ट एक फिक्स पर काम कर रहा है (2010 में सब कुछ ठीक है)। इसके प्रकाश में, मैंने विज़ुअल स्टूडियो का उपयोग नहीं करने का फैसला किया, खासकर जब से अंतिम परिणाम (क्लैंग द्वारा संकलित) विशेष रूप से प्रभावित नहीं होना चाहिए।

Mingw32 + MSYS । मिंगव 32 - इसमें जीसीसी और एक पतला आवरण होता है जो कार्यक्रमों के लिए एक लिनक्स जैसा वातावरण लागू करता है, खिड़कियों का अनुवाद <> लिनक्स शैली पथ। विशिष्ट कार्य (जैसे कांटा) पूरी तरह से लागू नहीं होते हैं, क्योंकि संगतता साइबरविन से भी बदतर है, लेकिन यह तेजी से काम करता है। असेंबली प्रक्रिया का आंशिक विवरण llvm वेबसाइट पर है ।

MSYS - हमें एक "linux" शेल देता है जिसमें आप मानक बिल्ड स्क्रिप्ट चला सकते हैं। यह इस रास्ते के साथ है कि हम जाएंगे।

हम MSYS कंसोल शुरू करते हैं, llvm, clang, compiler-rt (असेंबली के लिए लो-लेवल सिस्टम कोड) के स्रोतों को डाउनलोड करते हैं, llvm को आपके सोर्स फोल्डर के रूट पर खोलते हैं, llvm / प्रोजेक्ट्स के लिए llvm / tools, compiler-rt से चिपके रहते हैं। हम gcc के संस्करण की जाँच कर रहे हैं - llvm के लिए 3.2 gcc 4.6.2 की तुलना में बाद में उपयुक्त नहीं है (4.7.2 के बाद से, वह खुद का निर्माण नहीं कर सकता, लेकिन यह बहुत पुराना है)।

उसके बाद, बायनेरिज़ के लिए एक निर्देशिका बनाएं, उदाहरण के लिए llvm / bin, वहां जाएं, और कमांड निष्पादित करें:

../configure --disable-docs --enable-optimized --enable-targets=x86 --prefix=/newclang 

कॉन्फ़िगरेशन पूरा होने के बाद, हम लिखते हैं, और प्रोजेक्ट की असेंबली शुरू हो जाएगी। जब समाप्त होता है, हम कर सकते हैं स्थापित करें, और हमारे संकलित बायनेरिज़ को MSYS फ़ाइल सिस्टम के रूट में newclang निर्देशिका में लिखा जाएगा।

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

 export CXX=/newclang/bin/clang++.exe export CC=/newclang/bin/clang.exe 

संकलन के लिए एक नई निर्देशिका बनाएं, इसे फिर से चलाएँ ../configure..and फिर करें। लेकिन क्लैंग खुद ही इतनी आसानी से खुद को इकट्ठा नहीं करेगा, अन्यथा इस लेख का क्या मतलब होगा?

हम समस्याओं को ठीक करते हैं

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

 Export LDFLAGS=-static 

त्रुटि "केवल एलाका-वाइड स्टोर को विभाजित किया जा सकता है और पुन: स्थापित किया जा सकता है"
यह llvm में एक बग है , जो पहले से ही भंडार में तय किया गया है और 3.3 में जाएगा। लेकिन हाँ, क्लैंग 3.2 रिलीज इस वजह से खुद को इकट्ठा नहीं कर सकती है।

आपको svn 170270 संशोधन से फ़ाइल को \ lib \ Transforms \ Scalar \ SROApppp फ़ाइल में रोल करना होगा:

 =================================================================== --- SROA.cpp (revision 170269) +++ SROA.cpp (revision 170270) @@ -2607,7 +2607,7 @@ TD.getTypeStoreSizeInBits(V->getType()) && "Non-byte-multiple bit width"); assert(V->getType()->getIntegerBitWidth() == - TD.getTypeSizeInBits(OldAI.getAllocatedType()) && + TD.getTypeAllocSizeInBits(OldAI.getAllocatedType()) && "Only alloca-wide stores can be split and recomposed"); IntegerType *NarrowTy = Type::getIntNTy(SI.getContext(), Size * 8); V = extractInteger(TD, IRB, V, NarrowTy, BeginOffset, 

मल्टीप्रोसेसर विधानसभा जमा देता है
यदि आप बिल्ड को गति देने के लिए मेक -j 8 का उपयोग करते हैं - तो हां, mingw32 बिल्ड के बीच में कसकर लटका सकता है, कम से कम एसएसडी पर (ड्राइव तक पहुंचने में कोई देरी नहीं है - दौड़ की स्थिति का बेहतर मौका है)। मुझे कोई हल नहीं मिला।

क्लैंग को मानक पुस्तकालय नहीं मिल सकते हैं
जैसा कि हम याद करते हैं, यह gcc से मानक पुस्तकालयों का उपयोग करता है। उसे खोजने के लिए - उन्हें सही संस्करण होना चाहिए, और अपेक्षित क्लैंग जगह पर झूठ बोलना चाहिए।

कुर्सी से मत गिरो, फ़ाइलों को खोजने के लिए पथ फ़ाइल \ टूल्स \ clang \ lib \ Frontend \ InitHeaderSearch.cpp में हार्डकोड किया गया है। यदि आपका MinGW डिफ़ॉल्ट फ़ोल्डर में नहीं है, तो क्लैंग निश्चित रूप से नहीं मिलेगा। फिर, शीर्ष लेख फ़ाइलों के साथ निर्देशिका को खोजने के लिए केवल gcc के कुछ संस्करणों की जाँच करता है, सुनिश्चित करें कि आपके पास gcc का सही संस्करण है।

आप MSYS में आवश्यक संस्करण के पैकेज इस तरह से स्थापित कर सकते हैं:

 mingw-get install "gcc=4.6.*" mingw-get install "g++=4.6.*" 

अब क्लैंग खुद को इकट्ठा करने में सक्षम होगा, और आपको एक ताजा और तेज, गर्म और दीपक, आत्म-इकट्ठे संकलक मिलेगा।