क्रॉस संकलन के लिए मुझे लगता है कि आपके सर्वोत्तम विकल्प या तो CMake या Autotools हैं। विशेष रूप से यदि आप एकाधिक आर्किटेक्चर/प्लेटफार्मों के लिए अपना कोड संकलित कर सकते हैं। मैं आम तौर पर यूनिट परीक्षण उद्देश्यों के लिए मूल मशीन पर अपने कोड का सबसेट संकलित करता हूं और यह सब लक्ष्य प्लेटफॉर्म के लिए संकलित करता है। सीएमके इसे विशेष रूप से अच्छी तरह से संभालता है, क्योंकि यह आपको यह निर्दिष्ट करने देता है कि क्रॉस संकलित पुस्तकालय कहाँ रहते हैं। क्रॉस संकलित libpng/usr/lib में क्रॉस संकलित करने के बजाय, इसे/build/arm-eabi-gcc/या जहां भी आपके पास अपनी बिल्ड मशीन पर टूल चेन लाइब्रेरी स्थापित है, को देखने के लिए कहा जा सकता है। आप अलग-अलग प्रकारों के लिए कई बिल्ड निर्देशिका बना सकते हैं और मैन्युअल रूप से प्रत्येक संस्करण को संकलित कर सकते हैं, या ब्राइंडेड हैंड-रोलेड रिकर्सिव मेक के साथ बहुत कुछ ट्रिगर कर सकते हैं।
चींटी में यह कमी है कि यह वैनिला मेक के रूप में मूल रूप से अच्छा या बुरा है, इसके अतिरिक्त नुकसान जो आप सी या सी ++ के लिए विशेष रूप से मुख्यधारा नहीं कर रहे हैं। आपको अपनी सभी निर्भरताओं से निपटना होगा - आंतरिक दोनों, जैसे कि सी फ़ाइल को हेडर फ़ाइल में लाइब्रेरी या निष्पादन योग्य, और बाहरी निर्भरताओं जैसे तृतीय पक्ष पुस्तकालयों से जुड़ना। इसके अलावा मुझे नहीं लगता कि चींटी सी कार्यों को वास्तव में बहुत अधिक बनाए रखा जाता है। मैंने जो भी देखा है, वह एंट फॉर सी वकील का उपयोग निष्पादन कार्यों के साथ जीसीसी को बुला रहा है।
स्कॉन्स बेहतर है, लेकिन क्रॉस संकलन इसकी मजबूत बिंदु नहीं है। यह सीएमके या ऑटोटूल जैसे "निर्माण प्रणाली" नहीं है, यह केवल एक निर्माण उपकरण है। जैसा कि यह उनके विकी, it is pretty much "Make in Python" पर कहता है। यह निर्भरताओं के लिए संभालने में बनाया गया है, जिसका अर्थ है कि आपको "जीसीसी-एमएम-एमडी" या जो भी हो, वहां अपना खुद का रोल नहीं करना है, इसलिए यह मेक पर एक लाभ है। स्कैनों को तीसरे पक्ष के पुस्तकालयों का पता लगाने के लिए समर्थन भी मिलता है, लेकिन आमतौर पर जिस तरह से किया जाता है, वह आपके निर्माण समय में बहुत कुछ जोड़ सकता है। अन्य प्रणालियों के विपरीत, स्कैन प्रत्येक बार जब आप इसे चलाते हैं तो जांच चरण चलाता है, हालांकि अधिकांश परिणाम कैश किए जाते हैं। स्कैन अपने लंबे निर्माण के समय के लिए भी कुख्यात है, हालांकि 50 फाइलों के लिए जो कोई मुद्दा नहीं होगा। स्कॉन्स में क्रॉस संकलन समर्थन मौजूद नहीं है - आपको अपना खुद का as discussed on this thread on the mailing list रोल करना होगा। आमतौर पर आप निर्माण को यूनिक्स प्लेटफॉर्म की तरह मजबूर करते हैं, फिर सी कंपाइलर के नाम को ओवरराइड करते हैं। स्रोत निर्देशिका से कई प्रकार का निर्माण या निर्माण निर्देशिका को अलग करना गॉथस से भरा है, जो आपके कोड को पार और मूल रूप से संकलित करते समय इसे कम उपयुक्त बनाता है।
सीएमके और ऑटोोटूल की निर्भरता की समस्याएं काफी अच्छी तरह से लगती हैं, और ऑटोोटूल का क्रॉस संकलन समर्थन परिपक्व है। सीएमके के संस्करण 2.6.0 के बाद से क्रॉस संकलन हुआ है, जिसे अप्रैल 2008 में रिलीज़ किया गया था। आप उन सुविधाओं को मुफ्त में प्राप्त करते हैं, साथ ही पैकेजिंग और चल रहे यूनिट परीक्षण जैसे अन्य ("चेक करें" या इसी तरह के लक्ष्य)। इन दोनों उपकरणों के नकारात्मक पक्ष में उन्हें बूटस्ट्रैपिंग की आवश्यकता है।सीएमके के मामले में, आपको मेकफ़ाइल या विजुअल स्टूडियो समाधान फ़ाइलों को बनाने के लिए सीएमके बाइनरी स्थापित करने की आवश्यकता है। Autotools के मामले में यह थोड़ा अधिक जटिल है क्योंकि सॉफ़्टवेयर को संकलित करने वाले सभी को ऑटोमेक और ऑटोकॉन्फ़ स्थापित करने की आवश्यकता नहीं होगी, केवल उन लोगों को जिन्हें बिल्ड सिस्टम को बदलने की आवश्यकता है (नई फाइलों को बिल्ड सिस्टम को बदलने के रूप में गिना जाता है)। 2 चरण बूटस्ट्रैपिंग (config.ac -> कॉन्फ़िगर करें, कॉन्फ़िगर करें + Makefile.in -> मेकफ़ाइल) समझने के लिए अवधारणात्मक रूप से थोड़ा सा ट्रिकियर है।
संपादन के लिए: क्रॉस संकलन निर्माण प्रणालियों में एक अतिरिक्त सिरदर्द है जिसके कारण यह कार्यक्रमों और पुस्तकालयों के स्वत: पता लगाने में जटिलता को जोड़ता है। स्कैन इस समस्या से निपट नहीं पाते हैं, यह आपको सुलझाने के लिए छोड़ देता है। चींटी समान रूप से कुछ भी नहीं करता है। Autoconf ऑटोटूल केस में इसे संभालता है, लेकिन आपको कमांड लाइन पर "--with-libfoobar =/some/path" प्रदान करना पड़ सकता है जब आप लिंक चरण में/usr/lib का उपयोग करने का प्रयास करते समय टूटी हुई लिंक को कॉन्फ़िगर या सामना करते हैं । सीएमके का दृष्टिकोण टूलचैन फ़ाइल के साथ थोड़ा अधिक भारी है, लेकिन इसका मतलब है कि आपको अपने सभी टूल्स और लाइब्रेरीज़ (सीसी, सीईओक्स, रैनलिब, --with-ibfoo =, आदि) को निर्दिष्ट करने की आवश्यकता नहीं है क्योंकि उन्हें पता लगाया गया है एक मानक सम्मेलन। सिद्धांत रूप में आप उन्हें संकलित करने के लिए कई परियोजनाओं में उपयुक्त ढंग से तैयार की गई सीएमके टूलचैन फ़ाइल का पुन: उपयोग कर सकते हैं। अभ्यास में सीएमके आपके औसत हैकर के लिए सुविधाजनक बनाने के लिए पर्याप्त रूप से पर्याप्त नहीं है, हालांकि यह उपयोगी हो सकता है यदि आप एकाधिक स्वामित्व वाली परियोजनाएं बना रहे हैं।