2011-03-11 15 views
5

मेरे पास एक लाइब्रेरी है जो इसे नियंत्रित करने के लिए # परिभाषा का समर्थन करती है। हालांकि पुस्तकालय का उपयोग कई EXE परियोजनाओं द्वारा किया जा सकता है जो विभिन्न संस्करण चाहते हैं। क्या मैं ऐप/EXE प्रोजेक्ट को लाइब्रेरी द्वारा निर्मित होने के लिए #define सेट कर सकता हूं, या इसे समाधान में सेट कर सकता हूं?क्या आप लोड की गई परियोजनाओं पर वीसी ++ समाधान सेट प्रीप्रोसेसर # डिफाईन्स बना सकते हैं?

लाइब्रेरी प्रोजेक्ट पर एक अलग बिल्ड-कॉन्फ़िगरेशन बनाने का एकमात्र अन्य विकल्प है, लेकिन यह जल्दी से नियंत्रण से बाहर हो जाएगा। यह यूनिकोड/गैर-यूनिकोड बनाता है, लेकिन फिर आप प्रत्येक संयोजन के लिए कॉन्फ़िगरेशन की संख्या गुणा करना समाप्त कर देंगे।

+1

एक 'config.h' फ़ाइल का उपयोग करें जो आवश्यक प्रीप्रोसेसर परिभाषित करता है, जो लाइब्रेरी प्रोजेक्ट द्वारा शामिल किया गया है, लेकिन एप्लिकेशन प्रोजेक्ट्स द्वारा प्रदान किया गया है (दोष: आपके पास प्रति समाधान फ़ाइल 1 से अधिक एप्लिकेशन प्रोजेक्ट नहीं हो सकता है) – smerlin

+0

Isn' यह वही है जो librik सुझाव देता है? –

+0

हां, वास्तव में .. बस उस जवाब को देखा (हालांकि मेरी टिप्पणी 5 घंटे बाद ..strange लिखा गया था)। – smerlin

उत्तर

5

निम्न दृष्टिकोण मानता है कि प्रत्येक .EXE/ऐप (जो इस लाइब्रेरी का उपयोग करता है) का अपना विजुअल स्टूडियो समाधान है।

आपके पास लाइब्रेरी पर नियंत्रण है, है ना? चरण 1-3 अपनी प्रोजेक्ट फ़ाइल में परिवर्तन करेगा, और चरण 4 लाइब्रेरी स्रोत कोड में एक फ़ाइल जोड़ता है।

  1. सेट प्रोजेक्ट गुण> C/C++> उन्नत> सेना mylibrary_solution_defines.h को भी शामिल है।

  2. प्रोजेक्ट गुणों को संपादित करें> सी/सी ++> सामान्य> निर्देशिकाओं की सूची की शुरुआत में $(SolutionDir); डालने के लिए अतिरिक्त निर्देशिकाएं शामिल करें।

  3. समाधान निर्देशिका से संबंधित कुछ चीज़ों के लिए परियोजना गुण> सामान्य> आउटपुट निर्देशिका और इंटरमीडिएट निर्देशिका दोनों सेट करें। शायद $(SolutionDir)$(ProjectName)\$(Configuration)? आप यह सुनिश्चित करना चाहते हैं कि पुस्तकालय को हर समाधान के लिए पुनर्निर्मित किया जाए जो इसका उपयोग करता है; .lib या .obj फ़ाइलों का कोई साझाकरण नहीं होना चाहिए।

  4. mylibrary_solution_defines.h नामक एक खाली, डमी हेडर फ़ाइल बनाएं और इसे अपने लाइब्रेरी स्रोत कोड में रखें ताकि #include "mylibrary_solution_defines.h" कभी असफल न हो।

  5. प्रत्येक ऐप/EXE समाधान में - यह मानते हुए कि आपके पास इस लाइब्रेरी का उपयोग करने वाले प्रत्येक ऐप के लिए अलग-अलग समाधान हैं, अन्यथा यह पूरी योजना विफल हो जाएगी - इसमें mylibrary_solution_defines.h फ़ाइल बनाएं जिसमें आपकी # परिभाषाएं हैं।

क्या आप देखते हैं कि क्या हो रहा है? प्रत्येक लाइब्रेरी स्रोत फ़ाइल निहित #include एस "mylibrary_solution_defines.h", और यह वरीयता से उस निर्देशिका को समाधान निर्देशिका से प्राप्त करती है। ताकि फ़ाइल हर समाधान के लिए अलग हो। इसलिए यदि आपका समाधान ConsoleModeInterfaceProgram.sln को #define TEXTONLY 1 के साथ निर्मित लाइब्रेरी की आवश्यकता है, तो उस पंक्ति को mylibrary_solution_defines.h पर रखें जो ConsoleModeInterfaceProgram.sln के समान निर्देशिका में है।

+0

धन्यवाद, थोड़ी देर के लिए इसका समाधान ढूंढ रहे हैं – Paulus

0

आपको प्रत्येक लाइब्रेरी संस्करण के लिए अलग-अलग बिल्ड कॉन्फ़िगरेशन की आवश्यकता होगी जिसमें आपके किसी भी एप्लिकेशन की आवश्यकता है। इस तरह निर्माण प्रणाली तैयार की गई है।

'लाइब्रेरी' के लिए सीधे स्रोत एप्लिकेशन को स्रोत कोड जोड़ने और प्रति प्री-प्रोजेक्ट सही प्रीप्रोसेसर सेटिंग्स सेट करने का एकमात्र तरीका होगा - इस तरह, आपको अभी भी साझा कोडबेस का लाभ है।

+0

यह भयानक है :(। एन ऐसी सेटिंग्स के लिए आपके पास 2^एन बिल्ड-कॉन्फ़िगर हैं।मुझे उम्मीद थी कि मैं एक प्रोजेक्ट को निर्भरता पर एक सेटिंग इंजेक्ट कर सकता हूं या प्री-बिल्ड सेटिंग का उपयोग कर सकता हूं, या कुछ समाधान-स्तरीय सेटिंग्स थीं। ओह अच्छा। –

संबंधित मुद्दे

 संबंधित मुद्दे