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

Question

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

मेरे पास एक प्रोजेक्ट है (मैं इसे माइप्रोजेक्ट कहूंगा) जिसमें एक और प्रोजेक्ट (विक्रेता) शामिल है। विक्रेता परियोजना किसी और द्वारा बनाए रखा एक स्टैंडअलोन परियोजना है। इस तरह की एक परियोजना सहित काफी straightforward है, लेकिन इस मामले में एक छोटा सा स्नैग है: प्रत्येक प्रोजेक्ट अपनी 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 खोज के साथ चालू करने में सक्षम हूं, this ऑटोमेक मेलिंग सूची पर थ्रेड है, जो पूरी तरह से सहायता नहीं है। क्या किसी और के पास कोई बेहतर विचार है?

Answer 1

कुछ नोट:

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

Answer 2

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

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

यह हमारे निर्माण वातावरण में संतोषजनक है, लेकिन मैं एक क्लीनर तरीका में रुचि होगी।

Answer 3

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

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