جزئية يبني مقابل كاملة يبني في Visual C++

Question

معظم حياتي تطوير العمل مع Visual C++, أنا باستخدام جزئي يبني مثلاضغط المفتاح F7 و غيرت فقط C++ الملفات تبعيات على إعادة بنائها ، تليها تدريجي الرابط.قبل تمرير نسخة على الاختبار انا اتخاذ الاحتياطات من القيام بناء كامل ، والتي تستغرق حوالي 45 دقيقة على المشروع الحالي.لقد رأيت العديد من المشاركات والمقالات الدعوة إلى هذا العمل ، ولكن أتساءل هل هذا ضروري ، وإذا كان الأمر كذلك, لماذا ؟ أنها لا تؤثر على تسليم EXE أو المرتبطة بها PDB (ونحن أيضا استخدام اختبار)?أن البرنامج وظيفة مختلفة عن اختبار المنظور ؟

من أجل الإفراج عن يبني, أنا باستخدام VS2005 الإضافية تجميع و ربط ، المشغلات الأساسية.

Answer 1

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

وهذا في حد ذاته يبدو لي أن يكون سببا كافيا للقيام إعادة بناء بالكامل قبل الافراج عنهم.

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

Answer 2

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

وتحرير: وبطبيعة الحال، والقيام كاملة إعادة بناء أيضا الدروع لكم من الخلل المحتملة في نظام بناء تدريجي

Answer 3

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

Answer 4

وأنا بالتأكيد أوصى به. لقد رأيت في عدد من المناسبات مع حل كبير C ++ مرئي تفشل المدقق التبعية لالتقاط بعض الاعتماد على كود تغير. عندما يكون هذا التغيير هو ملف رأس أن يؤثر حجم كائن أشياء غريبة جدا يمكن أن تبدأ أن يحدث. أنا واثق من أن المدقق التبعية قد حصلت أفضل في VS 2008، ولكن ما زلت لا تثق به لإنشاء إصدار.

Answer 5

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

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

Answer 6

Visual Studio لديه بعض المشاكل مع جزئية (تدريجي) يبني (أنا في الغالب واجهت أخطاء الارتباط) من الوقت إلى الوقت ، فإنه من المفيد جدا أن يكون بناء كامل.

في حالة طويلة تجميع مرات ، هناك نوعان من الحلول:

1. استخدام مواز تجميع أداة الاستفادة من (المفترض) متعدد الأجهزة الأساسية.
2. استخدام بناء آلة.ما يمكنني استخدام أكثر هو منفصل بناء آلة, مع CruiseControl إعداد هذا يؤدي الكامل يعيد من وقت لآخر."الرسمي" الإفراج عن أن أقدمها إلى فريق الاختبار في نهاية المطاف إلى العملاء هو دائما مأخوذة من بناء آلة, ليس من المطور البيئة.