2009-05-27 12 views
5

मेरे पास एक सी ++ ऑटोकॉन्फ़ प्रबंधित प्रोजेक्ट है जिसे मैं फ्रीबीएसडी होस्ट पर संकलित करने के लिए अनुकूल हूं। मूल प्रणाली लिनक्स थी इसलिए मैंने एक मेजबान को अलग करने के लिए एक AM_CONDITIONAL बनाया और कोड को सिस्टम विशिष्ट फ़ाइलों में अलग कर दिया।ऑटोमैक और उसी नाम वाली फाइलें

configure.ac

 

AC_CANONICAL_HOST 
AM_CONDITIONAL([IS_FREEBSD],false) 
case $host in 
     *free*)  
      AC_DEFINE([IS_FREEBSD],[1],[FreeBSD Host]) 
      AM_CONDITIONAL([IS_FREEBSD],true) 
      BP_ADD_LDFLAG([-L/usr/local/lib]) 
       ;; 
esac 

Makefile.am

 

lib_LTLIBRARIES=mylib.la 
mylib_la_SOURCES=a.cpp \ 
       b.cpp 

if IS_FREEBSD 
    mylib_la_SOURCES+=freebsd/c.cpp 
else 
    mylib_la_SOURCES+=linux/c.cpp 
endif 

जब मैं automake यह संदेश इस तरह से विफल रहता है चलाएँ:

 
Makefile.am: object `c.lo' created by `linux/c.cpp' and `freebsd/c.cpp' 

कैसे automake कॉन्फ़िगर करने के लिए पर कोई भी विचार Makefile.in में भी इस सशर्त का सम्मान करने के लिए proccess निर्माण?

मैं इस काम करता है फ़ाइलें विभिन्न नाम है, लेकिन यह C++ कोड है और मैं फ़ाइल नाम वर्ग के नाम के रूप में ही रखने की कोशिश कर रहा हूँ।

अग्रिम धन्यवाद!

+1

आपके मेकफ़ाइल.एम में एक टाइपो है: "IS_FREEBSD" को "IS_FREEBSD" पढ़ना चाहिए। – adl

+0

धन्यवाद adl, संशोधित –

उत्तर

11

आप वस्तुओं के लिए अनुरोध कर सकता है के अलावा subdir-वस्तुओं, प्रत्येक उप परियोजना कुछ कस्टम प्रति-परियोजना झंडे का निर्माण दे रहा है,

AUTOMAKE_OPTIONS = subdir-objects 
+1

बिल्कुल सही जवाब, केवल यह कहना है कि यह एक Makefile.am विकल्प है! धन्यवाद !!! –

+5

'config.ac' में 'AM_INIT_AUTOMAKE ([... subdir-items ...]) में इस automake विकल्प को कॉन्फ़िगर करना भी संभव है। – ndim

+0

स्वचालित रूप से कोड के लिए ऑब्जेक्ट फ़ाइलों को क्यों बनाते हैं जिन्हें निर्माण करने के लिए नहीं कहा जाता है? चूंकि यह किसी शर्त पर संकलित है, इसलिए इसे एक ही समय में केवल एक फ़ाइल लेनी चाहिए, भले ही यह एक ही नाम में हो। क्या मैं सही हू? –

7

एक अन्य विकल्प के साथ अपने-अपने उपनिर्देशिका में निर्मित किया जाना। जब आप ऐसा करते हैं, तो स्वचालित नाम मॉड्यूल नाम पर लक्ष्य नाम को प्रीपेड करने के लिए अपने * .o नामकरण नियमों को बदलता है। उदाहरण के लिए, इस:

mylib_la_CXXFLAGS=$(AM_CXXFLAGS) 
mylib_la_SOURCES=a.cpp b.cpp 

उत्पादन फ़ाइलों mylib_la-a.o और mylib_la-b.o, बल्कि a.o और b.o. से में परिणाम होगा इस प्रकार आपके पास एक ही आउटपुट निर्देशिका के साथ दो अलग-अलग प्रोजेक्ट हो सकते हैं जिनमें प्रत्येक के पास एक b.cpp फ़ाइल है, और उनके आउटपुट संघर्ष नहीं हैं।

ध्यान दें कि मैंने प्रोजेक्ट-विशिष्ट CXXFLAGS को स्वचालित रूप से उपयोग करने जा रहे मानों के लिए प्रोजेक्ट-विशिष्ट CXXFLAGS सेट करके ऐसा किया है, AM_CXXFLAGS। Automake इस चाल का पता लगाने के लिए पर्याप्त स्मार्ट नहीं है और छोटे * .o नामों का उपयोग करें। यदि ऐसा होता है कि आपको प्रति-परियोजना निर्माण विकल्पों की आवश्यकता है, तो आप निश्चित रूप से इस हैक की बजाय ऐसा कर सकते हैं।

ऑटोकेक चर के whole list है, जो प्रति निष्पादन योग्य आधार पर सेट करते हैं, वही प्रभाव दें। तो उदाहरण के लिए, हो सकता है एक उप-परियोजना विशेष कड़ी झंडे को पहले से ही की जरूरत है, तो आप इसे की तरह कुछ दे:

mylib_la_LDFLAGS=-lfoo 

यह आपको पहले से जुड़ा हुआ * ओ फ़ाइलें AM_CXXFLAGS चाल किया था बस के रूप में दे देंगे, केवल अब आप कर रहे हैं इसे करने में automake को धोखा देने के बजाय, इस सुविधा का उपयोग करके "वैध रूप से"।

वैसे, यह कैसे अपने कार्यक्रम पूरी तरह से ओएस इसके लिए बनाया जा रहा है के आधार पर बनाता है बदलने के लिए बुरा autoconf शैली है। अच्छी ऑटोकॉन्फ शैली केवल प्लेटफॉर्म बदलने के कारण, विशिष्ट प्लेटफार्म सुविधाओं के लिए विशिष्ट प्लेटफार्म सुविधाओं के लिए जांचना है। FreeBSD एक निश्चित तरीके से आज हो सकता है, लेकिन शायद अगली फिल्म में यह लिनक्स से एक विशेषता यह है कि आप अपने कार्यक्रम दो अलग अलग तरीकों का निर्माण करने के लिए की जरूरत को मिटा होगा कॉपी कर देंगे। या, हो सकता है कि आप आज जिस सुविधा का उपयोग कर रहे हैं उसे बहिष्कृत कर दिया गया है, और अगले संस्करण में गिरा दिया जाएगा।

autotools में पोर्टेबल यूनिक्स प्रोग्रामिंग ज्ञान, टिड्डी के चालीस साल नहीं है।से ऊपर दिए गए "मेबेस" में अतीत में हुआ है, और निश्चित रूप से ऐसा फिर से करेगा। व्यक्तिगत सुविधाओं का परीक्षण लगातार बदलते प्लेटफॉर्म से निपटने का सबसे आसान तरीका है।

आप इस दृष्टिकोण से अप्रत्याशित बोनस भी प्राप्त कर सकते हैं। उदाहरण के लिए, हो सकता है कि आपके प्रोग्राम को अपना काम करने के लिए दो गैर-पोर्टेबल सुविधाओं की आवश्यकता हो। कहें कि फ्रीबीएसडी पर, ये ए और बी विशेषताएं हैं, और लिनक्स पर, वे एक्स और वाई विशेषताएं हैं; ए और एक्स समान तंत्र हैं, लेकिन विभिन्न इंटरफेस के साथ, और बी और वाई के लिए भी यही है। यह विशेषता ए मूल बीएसडी से आती है, और सोलारिस में है क्योंकि इसमें 80 के दशक में सनोस से बीएसडी की जड़ें हैं, और सोलारिस में भी है इसके शुरुआती 9 0 के दशक में सिस्टम वी आधारित रीडिज़ाइन से फीचर वाई। इन सुविधाओं के परीक्षण के द्वारा, आपका प्रोग्राम सोलारिस पर भी चल सकता है, क्योंकि इसमें आपके प्रोग्राम की ज़रूरत है, केवल फ्रीबीएसडी और लिनक्स के समान संयोजन में नहीं।

+4

+1 "सुविधाओं के लिए जांच करें, प्लेटफ़ॉर्म नहीं" के लिए +1। –

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