مشاركة الرؤوس المترجمة مسبقًا بين المشاريع في Visual Studio

Question

لدي حل للعديد من مشاريع Visual C++، وكلها تستخدم PCH، ولكن بعضها يحتوي على مفاتيح تحويل خاصة للمترجم قيد التشغيل لتلبية الاحتياجات الخاصة بالمشروع.

تشترك معظم هذه المشاريع في نفس مجموعة الرؤوس في ملف stdafx.h الخاص بها (STL، Boost، إلخ).أتساءل عما إذا كان من الممكن مشاركة PCH بين المشاريع، بحيث بدلاً من تجميع كل PCH لكل مشروع، ربما يمكنني الحصول على PCH مشترك واحد يمكن أن تستخدمه معظم المشاريع في الحل.

يبدو أنه من الممكن تحديد موقع PCH كموقع مشترك في إعدادات المشروع، لذلك لدي حدس أن هذا يمكن أن ينجح.أفترض أيضًا أن جميع الملفات المصدر في جميع المشاريع التي تستخدم PCH مشتركًا يجب أن يكون لها نفس إعدادات المترجم، وإلا فإن المترجم سيشكو من عدم الاتساق بين PCH والملف المصدر الذي يتم تجميعه.

هل هناك اي احد جرب هذة؟هل يعمل؟

سؤال ذو صلة:هل يجب أن يكون مثل هذا PCH الشامل شاملاً بشكل مفرط، أم أن ذلك سيضر بوقت البناء الإجمالي؟على سبيل المثال، يمكن أن تتضمن PCH المشتركة العديد من رؤوس STL المستخدمة على نطاق واسع، ولكن قد تحتاج بعض المشاريع فقط إلى <string> و <vector>.هل يجب سداد الوقت الذي تم توفيره باستخدام PCH مشترك في مرحلة لاحقة من عملية الإنشاء عندما يتعين على المُحسِّن تجاهل كافة العناصر غير المستخدمة التي تم سحبها إلى المشروع بواسطة PCH؟

Answer 1

ونعم من الممكن، وأستطيع أن أؤكد لكم، وتوفير الوقت كبيرة. عند ترجمة PCH، لديك لنسخ .pdb و.idb الملفات من المشروع الذي إنشاء ملف PCH. في حالتي، لدي مشروع ملف اثنين بسيط هو أن إنشاء ملف PCH. ورأس يكون رأس PCH وسيتم وقال المصدر لإنشاء PCH تحت إعدادات المشروع - وهذا هو على غرار ما تفعل عادة في أي مشروع. كما ذكرت، أن يكون لديك نفس الإعدادات التحويل البرمجي لكل التكوين وإلا تناقض تنشأ وسوف مترجم يشكو.

ونسخ الملفات المذكورة أعلاه في كل مرة كان هناك إعادة بناء أو في كل مرة يتم معاد للPCH سيكون الألم، ولذا فإننا سوف أتمتة عليه. لأتمتة النسخ، وإجراء الحدث ما قبل البناء حيث يتم نسخ الملفات المذكورة أعلاه أكثر من الدليل المناسب. على سبيل المثال، إذا كنت تقوم بتجميع Debug وRelease يبني من PCH، نسخ الملفات من Debug مشروع PCH فوق لDebug المشروع يعتمد الخاص بك. ولذلك فإن الأمر copy قد تبدو هذه

<اقتباس فقرة>   

ونسخ PchPath \ تصحيح * .PDB تصحيح \ / -Y

لاحظ /-Y في نهاية المطاف. بعد بناء أول، يتم تصنيف كل بناء لاحق تدريجيا، لذلك إذا قمت باستبدال الملفات مرة أخرى، والبصرية ستوديو يشكو حرف معطوب. إذا فعلوا ذلك للتلف، يمكنك تنفيذ دائما إعادة بناء، والتي سوف نسخ الملفات مرة أخرى (هذه المرة لن القفز عليها لأنها لم تعد موجودة - تنظيف حذف الملفات).

وآمل أن يساعد هذا. استغرق الأمر مني بعض الوقت لتكون قادرة على القيام بذلك، ولكنه كان يستحق كل هذا العناء. لدي العديد من المشاريع التي تعتمد على إطار واحد كبير، وPCH يحتاج إلى أن يكون ترجمة مرة واحدة فقط. جميع المشاريع التي تعتمد الآن تجميع بسرعة كبيرة.

<اقتباس فقرة>   

وتحرير: جنبا إلى جنب مع عدة أشخاص آخرين، لقد جربت هذا تحت VS2010   وVS2012 وأنه لا يبدو للعمل بشكل صحيح.

Answer 2

على الرغم من أن هذا سؤال قديم، إلا أنني أريد أن أقدم إجابة جديدة تعمل في Visual Studio 2017 ولا تتضمن أي نسخ.العيب الوحيد:التحرير والمتابعة لا يعمل بعد الآن.

يجب عليك في الأساس إنشاء مشروع جديد للرأس المترجم مسبقًا وجعل جميع المشاريع الأخرى تعتمد عليه.وهنا ما فعلته:

خطوة بخطوة:

1. قم بإنشاء مشروع جديد داخل الحل الخاص بك والذي يتضمن الرأس (يسمى pch.h من هنا) وملف cpp من سطر واحد يتضمن pch.h.يجب أن يقوم المشروع بإنشاء lib ثابت.قم بإعداد المشروع الجديد لإنشاء رأس مترجم مسبقًا.يجب أن يكون ملف الإخراج متاحًا لجميع المشاريع.بالنسبة لي، هذا يتعلق بـ IntDir، ولكن بالنسبة للإعدادات الافتراضية، فقد يكون مرتبطًا بـ $(SolutionDir).يجب أن يحدد مشروع pch فقط جميع المشاريع الأخرى أيضًا.

   

2. جعل جميع المشاريع الأخرى تعتمد على هذا المشروع الجديد.وإلا فقد يكون ترتيب البناء خاطئًا.

   

3. قم بإعداد كافة المشاريع الأخرى لاستخدام pch.h.انظر كيف أن معلمات ملف الإخراج هي نفسها الموجودة في مشروع pch.تحتاج أدلة التضمين الإضافية أيضًا إلى الإشارة إلى دليل pch.h.اختياريًا، يمكنك فرض تضمين ملف pch في كل ملف cpp (أو يمكنك تضمينه يدويًا في السطر الأول من كل ملف cpp).

   

   4. قم بإعداد كافة المشاريع (بما في ذلك مشروع pch) لاستخدام نفس ملف رمز المترجم (لا يتأثر ملف رمز الرابط).مرة أخرى، في مثالي هذا هو OutDir ولكن في الحل الخاص بك قد يختلف هذا.يجب أن يشير إلى نفس الملف الموجود على القرص.يجب ضبط تنسيق معلومات التصحيح على C7 (انظر لقطة الشاشة أعلاه)، وإلا فلن يتمكن Visual Studio من تجميع المشاريع بالتوازي.

آمل أنني لم أنس أي شيء.بالنسبة للحل الخاص بي (130 ألف موقع، 160 مشروعًا) يؤدي هذا إلى وقت تجميع يصل إلى 2:30 دقيقة تقريبًا بدلاً من 3:30 دقيقة تقريبًا.

Answer 3

ويبدو أنه من غير الممكن لأن كل ملف المصدر أن يكون ترجمة ضد نفس PDB ضد الذي تم إعداده في PCH. الرتق ذلك.

Answer 4

والجواب Samaursa وعملت بالنسبة لي.

ورأيت أيضا هذا رابط أن يعمل (ابحث عن الجواب ريجنالد بالقرب من أسفل).

وهذا واحد يستخدم copy بينما ريجنالد لاستخدامات xcopy (أنا أفضل xcopy). وفي كلتا الحالتين، وذلك بفضل - وهذا تسرع بلدي يبني كبير

Answer 5

وهذا يبدو وكأنه حالة "تناقص الغلة" بالنسبة لي. لنفترض بما في ذلك رؤوس المشتركة يهدر مباشرة 1 ثانية لكل ملف .cpp، وكل هدف (DLL / EXE) له 10 ملفات .CPP. باستخدام .pch لكل هدف، يمكنك حفظ 10 ثانية لكل هدف. إذا كان المشروع كله لديه 10 أهداف، يمكنك حفظ 1.5 دقيقة على بناء كله، وهو أمر جيد.

ولكن بتخفيضه إلى .pch واحد للمشروع بأكمله، وكنت انقاذ سوى مزيد من 9 ثوان. هل تستحق ذلك؟ مزيدا من الجهد (والتي قد تكون أكثر فيدلي لاقامة، ويجري تكوين غير قياسي غير معتمد من قبل المعالجات VS) لا تنتج سوى 10 من الادخار.