4.5. ردیابی ساخت
هشدار
این مفهوم به طور کامل در حال حاضر آزمایشی است و ممکن است تغییر کند.
ردیابی ساخت (build trace) یک جدول یادداشتسازی (memoization table) برای ساختها است. این ابزار، ورودیهای ساختها را به خروجیهای ساختها نگاشت میکند. هر [ورودی] در ردیابی ساخت، یک derivation را به نگاشتی از نامهای output به اشیای انبار نگاشت میکند.
به طور کلی، derivationهای استفادهشده به عنوان کلید باید برطرف (resolved) شوند. یک ردیابی ساخت با کلیدهای derivation برطرفشده برای شفافیت بیشتر، ردیابی ساخت پایه (base build trace) نیز نامیده میشود. اگر تمام ورودیهای برطرفشدهی یک derivation از نوع آدرسدهیشده بر اساس محتوا (content-addressed) باشند، یعنی ورودیها کاملاً مشخص خواهند شد و هیچ ابهامی برای اینکه چه ساختی انجام شده است باقی نمیماند. (با این حال، ورودیهای آدرسدهیشده بر اساس ورودی همچنان مبهم هستند. آنها نیز باید قفل شوند، اما این کار برای نسخههای بعدی در نظر گرفته شده است.)
بر این اساس، برای جستجوی یک derivation برطرفنشده، ابتدا باید آن را برطرف کرد تا یک derivation برطرفشده به دست آید. خودِ فرآیند برطرفسازی شامل جستجوی ورودیها در ردیابی ساخت است، بنابراین این یک فرآیند متقابلاً بازگشتی است که در نهایت ممکن است ورودیهای بسیار زیادی را بررسی کند.
بهجز مسئلهی مربوط به مسیرهای آدرسدهیشده بر اساس ورودی که در بالا ذکر شد، ردیابیهای ساخت پایه بهطور پیشپاافتادهای سازگار (coherent) هستند — ناسازگاری در آنها غیرممکن است. این بدان معناست که ادعاهای مطرحشده توسط هر ورودی ردیابی ساخت پایهی کلید-مقدار، مستقل هستند و هیچ نگاشتی، نگاشت دیگری را باطل نمیکند.
اینکه آیا نگاشتها صحیح هستند، یعنی ثبت وفادارانهای از ساختهای واقعی انجامشده هستند یا خیر، موضوع دیگری است. سازگاری به این موضوع مربوط میشود که ادعاهای متعدد ردیابی ساخت با یکدیگر سازگار هستند، نه اینکه آیا ادعاها به طور جداگانه درست یا نادرست هستند.
به طور کلی، هیچ راهی برای حسابرسی یک ورودی ردیابی ساخت وجود ندارد، مگر با انجام مجدد ساخت از صفر. و حتی در آن صورت، نتیجهی متفاوت به این معنا نیست که ورودی اصلی یک «دروغ» بوده است، زیرا derivation در حال ساخت ممکن است غیرقطعی (non-deterministic) باشد. به همین دلیل، تصمیمگیری دربارهی اعتماد به ردیابی ساخت یک طرف دیگر، یک انتخاب سیاستگذاری کاملاً ذهنی است. ورودیهای ردیابی ساخت معمولاً به منظور امکانپذیر ساختن سیاستهای اعتماد مبتنی بر کلید عمومیِ دلخواه، امضا میشوند.
ردیابیهای ساخت مشتقشده
پیادهسازیهایی که مایلند موارد بالا را یادداشتسازی (memoize) کنند، ممکن است ورودیهای ردیابی ساخت مشتقشدهی اضافی را نیز نگه دارند که derivationهای برطرفنشده را نگاشت میکنند. اما اگر این کار را انجام دهند، باید ورودیهای پایهی زیرین را با کلیدهای derivation برطرفشده نیز حفظ کنند. اولاً، این کار تضمین میکند که ورودیهای مشتقشده صرفاً یک کش هستند که میتوانند از صفر دوباره محاسبه شوند. ثانیاً، این امر سازگاری ردیابی ساخت مشتقشده را تضمین میکند.
برخلاف ردیابیهای ساخت پایه، ناسازگاری در ردیابیهای ساخت مشتقشده امکانپذیر است. عنصر کلیدی این است که برطرفسازی derivation فقط نسبت به یک ردیابی ساخت پایهی ثابت، قطعی است. بدون ثابت کردن ردیابی ساخت پایه، این ویژگی، ذهنی بودنِ خودِ ردیابیهای ساخت پایه را به ارث میبرد.
به طور مشخص، فرض کنید سه derivation به نامهای \(a\)، \(b\) و \(c\) وجود دارند. فرض کنید \(a\) یک derivation برطرفشده باشد، اما \(b\) و \(c\) برطرفنشده باشند و هر دو خروجیِ \(a\) را به عنوان ورودی دریافت کنند. اکنون فرض کنید ورودیهای مشتقشده برای \(b\) و \(c\) بر اساس دو ورودی مختلف از \(a\) ساخته شوند. (این وضعیت میتواند زمانی رخ دهد که \(a\) غیرقطعی باشد، \(a\) و \(b\) در یک انبار ساخته شوند، \(a\) و \(c\) در انبار دیگری ساخته شوند، و سپس انبار سوم از هر دو انبار اول جایگزینی (substitute) کند.)
اگر اعتماد به ورودیهای ردیابی ساخت اشتقاق (derivation) برای \(b\) و \(c\) مستلزم این باشد که ورودی زیربنایی هر یک برای \(a\) نیز مورد اعتماد باشد، دو نگاشت مختلف برای \(a\) شناسایی خواهند شد. با این حال، اگر ورودیهای \(b\) و \(c\) بتوانند بهطور ایزوله ترکیب شوند، هیچ چیزی وجود نخواهد داشت تا تناقض موجود در فرضهای پنهان آنها دربارهی خروجی \(a\) را آشکار کند.