वर्जन, पैकेज इत्यादि को फिर से परिभाषित करने से कैसे बचें

मैंने जीएनयू ऑटोकॉन्फ़ / ऑटोमैटिक बिल्ड से संबंधित कोई प्रश्न नहीं देखा है, लेकिन मुझे उम्मीद है कि कम से कम आप में से कुछ इससे परिचित हैं। यहाँ जाता हैं:

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

... warning: "VERSION" redefined
... warning: this is the location of the previous definition
... warning: "PACKAGE" redefined
... warning: this is the location of the previous definition

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

0
ro fr bn

3 उत्तर

यह पता चला कि मेरे मामले में एक बहुत ही सरल समाधान था। विक्रेता प्रोजेक्ट कई शीर्षलेख फ़ाइलों को एक मोनोलिथिक हेडर फ़ाइल में एकत्र करता है, जो तब विक्रेता स्रोतों द्वारा # शामिल d होता है। लेकिन मोनोलिथिक हेडर बनाने वाले मेक नियम में गलती से जेनरेट config.h शामिल था। पैकेजिंग, संस्करण, आदि की उपस्थिति मोनोलिथिक हेडर में कॉन्फ़िगर चर वैरिएबल है जो Redefinition चेतावनियों का कारण बन रही थी। यह पता चला है कि विक्रेता का config.h अप्रासंगिक था, क्योंकि "config.h" हमेशा $ (top_builddir) /config.h पर हल हो जाता है।

मेरा मानना ​​है कि इस तरह से काम करना है। डिफ़ॉल्ट रूप से एक उपप्रोजेक्ट में संलग्न प्रोजेक्ट के config.h को इसके बजाय, जब तक उपप्रोजेक्ट स्पष्ट रूप से स्वयं शामिल नहीं होता है, या INCLUDE पथ में हेरफेर करता है, ताकि उसकी निर्देशिका $ ( top_builddir) , या अन्यथा मेरे मामले में हेडर फ़ाइलों में हेरफेर करता है।

0
जोड़ा

यह निश्चित रूप से एक हैक है, लेकिन मैं autogen'd config.h फ़ाइल को पोस्ट-प्रोसेस करता हूं:

sed -e 's/.*PACKAGE_.*//' < config.h > config.h.sed && mv config.h.sed config.h

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

0
जोड़ा

कुछ नोट्स:

  • आपने उल्लेख नहीं किया कि कैसे config.h को शामिल किया गया था - उद्धरण या कोण ब्रैकेट के साथ। अधिक जानकारी के लिए यह अन्य प्रश्न देखें अंतर। संक्षेप में, config.h आमतौर पर कोट्स के साथ शामिल होता है, कोण ब्रैकेट नहीं, और इससे प्रीप्रोसेसर को प्रोजेक्ट की अपनी निर्देशिका से config.h पसंद करना चाहिए (जो आमतौर पर होता है आप क्या चाहते हैं)
  • आप कहते हैं कि एक उपप्रोजेक्ट में संलग्न प्रोजेक्ट के config.h शामिल होना चाहिए, आम तौर पर यह वही नहीं है जो आप चाहते हैं। उपप्रोजेक्ट स्टैंडअलोन है, और इसका पैकेज और संस्करण उस सबप्रोजेक्ट में से एक होना चाहिए, न कि आपका। उदाहरण के लिए यदि आप अपने xmlreader प्रोजेक्ट में libxml शामिल करते हैं, तो आप अभी भी libxml कोड को PACKAGE libxml और VERSION (जो भी libxml संस्करण है) के साथ संकलित करना चाहते हैं।
  • आम तौर पर <head> config.h को सार्वजनिक शीर्षकों से शामिल करने की एक बड़ी गलती होती है। config.h हमेशा आपकी प्रोजेक्ट या उपप्रोजेक्ट के लिए निजी है, और केवल .c फ़ाइलों से ही शामिल किया जाना चाहिए। इसलिए, यदि आपके विक्रेता का प्रलेखन उनके "विक्रेता एच" को शामिल करने के लिए कहता है और सार्वजनिक हेडर में config.h शामिल है, तो यह नो-नो है। इसी प्रकार, यदि आपकी प्रोजेक्ट एक लाइब्रेरी है, तो अपने सार्वजनिक रूप से स्थापित शीर्षलेखों से कहीं भी config.h शामिल न करें।
0
जोड़ा