كيفية تجنب إعادة تعريف الإصدار والحزمة وما إلى ذلك

Question

لم أر أي أسئلة تتعلق ببنيات GNU autoconf/automake، لكني آمل أن يكون بعضكم على الأقل على دراية بها.هنا يذهب:

لدي مشروع (سأسميه مشروعي) يتضمن مشروعًا آخر (بائع).مشروع البائع هو مشروع مستقل يحتفظ به شخص آخر.بما في ذلك مشروع مثل هذا أمر عادل واضحة, ، ولكن في هذه الحالة هناك عقبة صغيرة:كل مشروع يولد الخاصة به config.h ملف، يحدد كل منه وحدات الماكرو القياسية مثل PACKAGE، VERSION، وما إلى ذلك.هذا يعني أنه أثناء الإنشاء، عندما يتم إنشاء البائع، أتلقى الكثير من الأخطاء مثل هذا:

... 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 هي هذا موضوع في القائمة البريدية لصناعة السيارات، وهو ما لا يقدم الكثير من المساعدة.هل لدى أي شخص آخر أي أفكار أفضل؟

Answer 1

بعض الملاحظات:

• لم تذكر كيف config.h تم تضمينه - مع علامات الاقتباس أو بين قوسين.يرى هذا السؤال الآخر لمزيد من المعلومات حول الفرق.باختصار، config.h عادةً ما يتم تضمينه مع علامات الاقتباس، وليس بين قوسين زاوية، وهذا من شأنه أن يجعل المعالج المسبق يفضل config.h من الدليل الخاص بالمشروع (والذي عادة ما يكون ما تريده)
• أنت تقول أن المشروع الفرعي يجب أن يتضمن المشروع المرفق config.h عادة هذا ليس ما تريده على الإطلاق.المشروع الفرعي مستقل، ويجب أن تكون الحزمة والإصدار الخاصين به من هذا المشروع الفرعي، وليس ملكك.إذا قمت بتضمين libxml في مشروع xmlreader الخاص بك على سبيل المثال، فستظل ترغب في تجميع كود libxml باستخدام PACKAGE libxml وVERSION (مهما كان إصدار libxml).
• عادة ما يكون من الخطأ الكبير أن يكون لديك config.h يتم تضمينها من الرؤوس العامة. config.h يكون دائمًا خاصًا بمشروعك أو المشروع الفرعي، ويجب تضمينه فقط من ملفات ‎.c.لذا، إذا كانت وثائق البائع تنص على تضمين "vendor.h" الخاص به ويتضمن ذلك الرأس العام config.h بطريقة أو بأخرى، فهذا لا لا.وبالمثل، إذا كان مشروعك عبارة عن مكتبة، فلا تقم بتضمينه config.h في أي مكان من الرؤوس المثبتة بشكل عام.

Answer 2

إنه بالتأكيد اختراق، لكني أقوم بمعالجة المولد التلقائي لاحقًا config.h ملف:

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

يعد هذا أمرًا مقبولًا في بيئة البناء الخاصة بنا ولكني سأكون مهتمًا بطريقة أنظف.

Answer 3

اتضح أن هناك حلًا بسيطًا جدًا في حالتي.يقوم مشروع البائع بتجميع عدة ملفات رأس في ملف رأس واحد متجانس، والذي يتم بعد ذلك #includeد من قبل مصادر البائعين.لكن قاعدة الإنشاء التي تبني الرأس المتجانس تتضمن عن طريق الخطأ ما تم إنشاؤه config.h.وجود الحزمة والإصدار وما إلى ذلك.متغيرات التكوين في الرأس المتجانس هي التي تسببت في تحذيرات إعادة التعريف.وتبين أن البائع config.h كان غير ذي صلة، لأن "config.h" يتم حله دائمًا $(top_builddir)/config.h.

أعتقد أن هذه هي الطريقة التي من المفترض أن تعمل بها.بشكل افتراضي، يجب أن يتضمن المشروع الفرعي المشروع المرفق config.h بدلاً من الخاص به، ما لم يتضمن المشروع الفرعي بشكل صريح خاصًا به، أو يعالج مسار INCLUDE بحيث يأتي الدليل الخاص به قبل $(top_builddir), أو يعالج ملفات الرأس كما في حالتي.