distcc(1) General Commands Manual distcc(1)

distcc - کامپایلر توزیع‌شده برای C/C++/ObjC به همراه افزونه‌های distcc-pump

distcc <compiler> [COMPILER OPTIONS]

distcc [COMPILER OPTIONS]

<compiler> [COMPILER OPTIONS]

distcc [DISTCC OPTIONS]

distcc کامپایل کدهای C را میان چندین دستگاه در یک شبکه توزیع می‌کند. distcc همیشه باید نتایجی مشابه کامپایل محلی تولید کند؛ نصب و استفاده از آن ساده است و اغلب بسیار سریع‌تر از کامپایل محلی عمل می‌کند.

این نسخه شامل distcc معمولی و همچنین بهبود جدیدی به نام حالت پمپ (pump mode) یا distcc-pump است.

برای هر کار، distcc در حالت معمولی کد منبع پیش‌پردازش‌شده کامل و آرگومان‌های کامپایلر را از طریق شبکه از کلاینت به یک سرور کامپایل ارسال می‌کند. در حالت پمپ، distcc کد منبع و پرونده‌های سرایند (header) اضافه شده به‌صورت بازگشتی (به‌جز موارد مربوط به شاخه‌های پیش‌فرض سرایند سیستم) را ارسال می‌کند، تا هم پیش‌پردازش و هم کامپایل روی سرورهای کامپایل انجام شود. این کار سرعت تحویل کامپایل‌ها را تا چندین برابر (تا یک مرتبه بزرگی) در مقایسه با distcc معمولی افزایش می‌دهد.

فرایند کامپایل توسط یک دستگاه کلاینت هدایت می‌شود که معمولاً ایستگاه کاری (workstation) یا لپ‌تاپ توسعه‌دهنده است. کلاینت distcc روی این دستگاه اجرا می‌شود، همان‌طور که make، پیش‌پردازنده (در صورتی که حالت پمپ distcc استفاده نشود)، پیونددهنده (linker) و سایر مراحل فرایند ساخت اجرا می‌شوند. هر تعداد دستگاه داوطلب به‌عنوان سرورهای کامپایل عمل کرده و با اجرای دیمن distccd(1) و در صورت نیاز کامپایلر C و اسمبلر، به کلاینت در ساخت برنامه کمک می‌کنند.

برنامه distcc می‌تواند از طریق سوکت‌های TCP (به‌طور پیش‌فرض روی درگاه ۳۶۳۲) یا از طریق یک دستور تونل مانند ssh(1) اجرا شود. برای اتصالات TCP، دستگاه‌های داوطلب باید دیمن distccd(1) را مستقیماً یا از طریق inetd اجرا کنند. برای اتصالات SSH، برنامه distccd باید نصب باشد اما نباید در انتظار اتصال‌ها گوش به زنگ (listening) باشد.

اتصالات TCP فقط باید در شبکه‌های امن استفاده شوند زیرا هیچ احراز هویت کاربری یا محافظتی از کد منبع یا کد هدف وجود ندارد. اتصالات SSH کندتر هستند.

ابزار distcc برای استفاده با گزینه -j در GNU Make در نظر گرفته شده است که چندین فرایند کامپایلر را به‌طور هم‌زمان اجرا می‌کند. distcc کارها را در پردازنده‌های محلی و راه دور پخش می‌کند. از آنجا که distcc قادر است بیشتر کارها را در سراسر شبکه توزیع کند، می‌توان از سطح هم‌زمانی بالاتری نسبت به ساخت‌های محلی استفاده کرد. به‌عنوان یک قاعده سرانگشتی، مقدار -j باید تقریباً دو برابر تعداد کل پردازنده‌های سرور در دسترس تنظیم شود، اما مشروط به محدودیت‌های کلاینت است. این تنظیم امکان تداخل حداکثری وظایفی را که منتظر ورودی/خروجی دیسک یا شبکه مسدود شده‌اند، فراهم می‌کند. توجه داشته باشید که distcc می‌تواند با ابزارهای کنترل ساخت دیگر مانند SCons نیز کار کند، که در آن‌ها تنظیمات هم‌زمانی مشابه باید اعمال شوند.

تنظیمات -j، به‌ویژه برای مقادیر بزرگ -j، باید بار پردازنده روی کلاینت را در نظر بگیرد. ممکن است اقدامات اضافی برای کاهش بار کلاینت لازم باشد. برای نمونه، پیوند دادن هم‌زمان باید با استفاده از قفل‌های کمکی به شدت مهار شود. اثر سایر فعالیت‌های ساخت، مانند کامپایل جاوا هنگام ساخت کدهای چندزبانه، باید در نظر گرفته شود. پارامتر --localslots_cpp به‌طور پیش‌فرض روی ۸ تنظیم شده است. این پارامتر تعداد فرایندهای هم‌زمانی را که در حالت distcc معمولی (غیر پمپ) پیش‌پردازش انجام می‌دهند محدود می‌کند. بنابراین، مقادیر -j بزرگ‌تر از ۸ را می‌توان بدون بارگذاری بیش از حد روی کلاینتِ تک‌پردازنده‌ای ناشی از پیش‌پردازش استفاده کرد. چنین مقادیر بزرگی ممکن است بخش‌هایی از فرایند ساخت را که شامل کامپایل C نیست تسریع کنند، اما ممکن است برای کارایی distcc در حالت معمولی مفید نباشند.

در مقابل، با استفاده از حالت پمپ و مثلاً ۴۰ سرور، تنظیم -j80 یا بزرگ‌تر حتی برای کلاینت‌های تک‌پردازنده‌ای ممکن است مناسب باشد.

اکیداً توصیه می‌شود که همان نسخه کامپایلر را روی تمام دستگاه‌های شرکت‌کننده در ساخت نصب کنید. کامپایلرهای ناسازگار ممکن است باعث شکست‌های مرموز در کامپایل یا پیوند شوند.

1
برای هر دستگاه، distcc را بارگیری کرده، از حالت فشرده خارج نموده و نصب کنید.
2
روی هر یک از سرورها، دستور distccd --daemon را همراه با گزینه‌های --allow برای محدود کردن دسترسی اجرا کنید.
3
نام‌های سرورها را در متغیر محیطی خود قرار دهید:
$ export DISTCC_HOSTS='localhost red green blue'
4
بسازید!
$ make -j8 CC=distcc

همانند بالا پیش بروید، اما در گام ۳، مشخص کنید که میزبان‌های دوردست باید بار پیش‌پردازش را به دوش بکشند و پرونده‌های ارسال‌شده از طریق شبکه باید فشرده شوند:

$ export DISTCC_HOSTS='--randomize localhost red,cpp,lzo green,cpp,lzo blue,cpp,lzo'

گزینه --randomize استفاده یکنواخت از سرورهای کامپایل را اعمال می‌کند. در حالی که از حالت پمپ distcc با تنها چند سرور بهره‌مند می‌شوید، با پردازنده‌های سرور بیشتر (تا صدها عدد!) سود فزاینده‌ای به دست می‌آورید. ساخت خود را درون دستور pump قرار دهید، در اینجا با فرض ۱۰ سرور:

$ pump make -j20 CC=distcc

مطابق با QUICKSTART پیش بروید اما در گام ۳، مشخص کنید که میزبان‌های دوردست باید به طور متقابل با کلاینت احراز هویت کنند:

$ export DISTCC_HOSTS='--randomize localhost red,auth green,auth blue,auth'

اگر distccd تحت یک نام principal مشخص اجرا می‌شود، پیش از گام ۴ دستور زیر را اجرا کنید:

export DISTCC_PRINICIPAL=<name>

distcc همواره تنها کامپایلر و اسمبلر را از راه دور اجرا می‌کند. با distcc ساده، پیش‌پردازنده باید همیشه به صورت محلی اجرا شود، زیرا نیاز به دسترسی به فایل‌های سرآیند گوناگونی روی ماشین محلی دارد که ممکن است روی ماشین داوطلب حاضر نبوده، یا یکسان نباشند. پیونددهنده (linker) نیز به همین ترتیب نیاز دارد کتابخانه‌ها و فایل‌های شیء (object files) را بررسی کند، بنابراین باید به صورت محلی اجرا شود.

کامپایلر و اسمبلر تنها یک فایل ورودی دریافت می‌کنند (کد منبع پیش‌پردازش‌شده) و یک خروجی واحد تولید می‌کنند (فایل شیء). distcc این دو فایل را از طریق شبکه منتقل می‌کند و در نتیجه می‌تواند کامپایلر/اسمبلر را از راه دور اجرا کند.

خوشبختانه برای بیشتر برنامه‌ها اجرای پیش‌پردازنده نسبتاً کم‌هزینه است، و پیونددهنده نیز به ندرت فراخوانی می‌شود، بنابراین بخش عمده کار را می‌توان توزیع کرد.

ابزار distcc خط فرمان خود را بررسی می‌کند تا مشخص سازد کدام‌یک از این فازها فراخوانی می‌شوند و آیا می‌توان کار را توزیع کرد یا خیر.

در حالت pump، ابزار distcc پیش‌پردازنده را نیز از راه دور اجرا می‌کند. برای انجام این کار، پیش‌پردازنده باید به تمام فایل‌هایی که در صورت اجرای محلی به آن‌ها دسترسی پیدا می‌کرد، دسترسی داشته باشد. بنابراین در حالت pump، ابزار distcc تمام سرآیندهای گنجانده‌شده به صورت بازگشتی را به جز سرآیندهای پیش‌فرض سیستم گردآوری کرده و همراه با فایل منبع به سرور کامپایل می‌فرستد.

در حالت distcc-pump، سرور مجموعه تمام فایل‌های منبع را در یک دایرکتوری موقت باز می‌کند که شامل درختی از دایرکتوری‌هاست و بخشی از سیستم فایل مرتبط با پیش‌پردازش، از جمله پیوندهای نمادین (symbolic links) را منعکس می‌سازد.

سپس کامپایلر از مسیری در دایرکتوری موقت اجرا می‌شود که متناظر با دایرکتوری کاری فعلی روی کلاینت است. برای یافتن و ارسال صدها فایلی که اغلب بخشی از یک کامپایل منفرد هستند، حالت pump از یک الگوریتم تحلیل افزایشی include استفاده می‌کند. سرور include یک برنامه پایتون است که این الگوریتم را پیاده‌سازی می‌کند. دستور pump سرور include را راه‌اندازی می‌کند تا در طول ساخت بتواند به پرس‌وجوهای include ارسال‌شده از سوی دستورهای distcc پاسخ دهد.

سرور include از تحلیل ایستا روی زبان ماکروها برای مدیریت کامپایل شرطی و includeهای محاسبه‌شده استفاده می‌کند. این سرور از این ویژگی بهره می‌برد که وقتی یک فایل سرآیند معین از نظر includeها قبلاً تحلیل شده است، در صورت بدون تغییر ماندن تمام گزینه‌های include (گزینه‌های -I) (همراه با شرایط دیگر)، نیازی به تکرار آن نیست.

در پروژه‌های ساخت بزرگ، هر فایل سرآیند به طور میانگین صدها بار include می‌شود. با حالت distcc-pump هر یک از چنین فایل‌هایی به جای آنکه صدها بار پیش‌پردازش شوند، تنها چند بار یا شاید فقط یک بار تحلیل می‌شوند. همچنین، هر فایل منبع یا سرآیند اکنون تنها یک بار فشرده‌سازی می‌شود، زیرا سرور include فایل‌های فشرده‌شده را در حافظه موقت (memoize) ذخیره می‌کند. در نتیجه، زمان صرف‌شده برای آماده‌سازی کامپایل ممکن است تا یک مرتبه بزرگی نسبت به پیش‌پردازش در distcc ساده کاهش یابد.

از آنجا که distcc در حالت pump قادر است فایل‌ها را تا حدود ده برابر سریع‌تر ارسال کند، سرعت ساخت در پروژه‌های بزرگ در مقایسه با حالت ساده distcc ممکن است ۳ برابر یا بیشتر افزایش یابد.

استفاده از حالت pump نیازمند آن است که هم کلاینت و هم سرورها (به ترتیب) از نسخه 3.0 یا جدیدتر distcc و distccd استفاده کنند.

تحلیل افزایشی include در حالت distcc-pump متکی بر این فرض بنیادین است که فایل‌های منبع و سرآیند در طول فرایند ساخت تغییر نمی‌کنند. برخی سیستم‌های ساخت پیچیده، مانند آنچه در لینوکس کرنل 2.6 وجود دارد، این شرط را کاملاً برآورده نمی‌کنند. برای رفع چنین مسائلی و موارد خاص دیگر مانند مسیرهای مطلق فایل در includeها، صفحه راهنمای include_server(1) را ببینید.

یک فرض مهم دیگر این است که پیکربندی include در تمام ماشین‌ها باید یکسان باشد. بنابراین سرآیندهای موجود در مسیر پیش‌فرض سیستم باید در تمام سرورها و تمام کلاینت‌ها یکسان باشند. اگر یک نصب استاندارد کامپایلر GNU به کار رفته باشد، این شرط برای تمام کتابخانه‌هایی که فایل‌های سرآیند آن‌ها زیر /usr/include یا /usr/local/include/ نصب شده‌اند اعمال می‌شود. توجه داشته باشید که نصب بسته‌های نرم‌افزاری اغلب منجر به قرار گرفتن فایل‌های سرآیند بیشتر در زیردایرکتوری‌های هر یک از این دو می‌شود.

اگر این فرض برقرار نباشد، ممکن است فرایند ساخت با حالت distcc-pump دچار شکست شود، یا بدتر از آن، بدون هیچ هشداری نتایج نادرست به دست آید. در حال حاضر این شرط بررسی نمی‌شود و پرداختن به این موضوع در فهرست کارهای آتی (TODO) قرار دارد.

یک روش آسان برای تضمین یکسان بودن پیکربندی‌های include استفاده از یک کامپایلر متقاطع (cross-compiler) است که مسیر جستجوی پیش‌فرض سیستم را به دایرکتوری‌های مربوط به نصب کامپایلر محدود می‌کند.

برای اطلاعات بیشتر درباره نشانه‌ها و علل نقض فرضیات حالت distcc-pump، به راهنمای include_server(1) مراجعه کنید.

در این حالت، distcc از چارچوب GSS-API برای دسترسی به سازوکار امنیتی پیکربندی‌شده فعلی و انجام احراز هویت متقابل با دیمن (daemon) استفاده خواهد کرد.

بیشتر گزینه‌های ارسال‌شده به distcc به عنوان گزینه‌های کامپایلر تفسیر می‌شوند. گزینه‌های زیر توسط خود distcc درک و پردازش می‌شوند. اگر هر یک از این گزینه‌ها مشخص شود، distcc کامپایلر را فراخوانی نخواهد کرد.

دستورالعمل‌های خلاصه را نمایش می‌دهد.
نسخه کلاینت distcc را نمایش می‌دهد.
فهرست میزبان‌هایی را که distcc استفاده خواهد کرد نمایش می‌دهد. بخش مشخصات میزبان (Host Specifications) را ببینید.
فهرست فایل‌هایی را که distcc به ماشین راه دور ارسال خواهد کرد، بر اساس محاسبه سرور include، نمایش می‌دهد. این یک برآورد محافظه‌کارانه (بیش از حد) از فایل‌هایی است که توسط کامپایلر C خوانده خواهند شد. این گزینه تنها در حالت pump کار می‌کند. برای جزئیات مربوط به نحوه محاسبه، بخش «نحوه کارکرد حالت DISTCC-PUMP» را ببینید.

خروجی فهرست distcc --scan-includes شامل یک مدخل در هر خط خواهد بود. هر خط شامل یک دسته‌بندی و به دنبال آن یک مسیر است. دسته‌بندی یکی از موارد FILE، SYMLINK، DIRECTORY یا SYSTEMDIR است:

FILE نشان‌دهنده یک فایل منبع یا سرآیند است که به میزبان سرور distcc فرستاده می‌شود.
SYMLINK نشان‌دهنده یک پیوند نمادین است که به میزبان سرور distcc فرستاده می‌شود.
DIRECTORY نشان‌دهنده دایرکتوری‌ای است که ممکن است برای کامپایل فایل منبع مورد نیاز باشد. به عنوان مثال، دایرکتوری "foo" ممکن است به دلیل یک include به فرم #include "foo/../bar.h" لازم باشد. چنین دایرکتوری‌هایی روی میزبان سرور distcc ایجاد خواهند شد.
SYSTEMDIR نشان‌دهنده یک دایرکتوری include سیستم است، یعنی دایرکتوری‌ای که در مسیر include پیش‌فرض کامپایلر قرار دارد، مانند "/usr/include"؛ فرض بر این است که چنین دایرکتوری‌هایی روی میزبان سرور distcc موجود هستند، و بنابراین به میزبان سرور distcc ارسال نخواهند شد.
سطح همزمانی در distcc را، همان‌گونه که از فهرست میزبان‌ها محاسبه می‌شود، نمایش می‌دهد؛ این مقدار برابر است با حداکثر تعداد کارهای در جریان صادرشده از این کلاینت به تمام سرورها. به طور پیش‌فرض این مقدار چهار برابر تعداد میزبان‌های موجود در فهرست خواهد بود، مگر آنکه از گزینه /LIMIT در فهرست میزبان‌ها استفاده شده باشد. بخش مشخصات میزبان (Host Specifications) را ببینید.
نام security principal مربوط به distccd را که از محیط استخراج شده است، نمایش می‌دهد. این گزینه تنها زمانی در دسترس است که distcc با گزینه پیکربندی --with-auth کامپایل شده باشد.

سه روش مختلف برای فراخوانی distcc وجود دارد تا با شرایط گوناگون سازگار شود:

ابزار distcc می‌تواند تحت نام کامپایلر واقعی نصب شود تا فراخوانی‌های آن را رهگیری کرده و آن‌ها را از راه دور اجرا کند. این کامپایلر «تغییر چهره‌داده» (masqueraded) بیشترین سازگاری را با درخت‌های کد منبع موجود دارد و هنگامی که می‌خواهید از distcc برای همه فرآیندهای کامپایل استفاده کنید، بسیار مناسب است. این واقعیت که از distcc استفاده می‌شود، برای makefileها کاملاً نامحسوس و شفاف است.

می‌توان distcc را به ابتدای خطوط دستور کامپایلر افزود، مانند "distcc cc -c hello.c"; یا CC="distcc gcc". این روش هنگامی مناسب است که بخواهید از distcc تنها برای برخی کامپایل‌ها استفاده کنید یا آن را بیازمایید، اما ممکن است با برخی makefileها یا نسخه‌هایی از libtool که فرض می‌کنند $CC حاوی فاصله نیست، ایجاد مشکل کند.

در نهایت، می‌توان از distcc به طور مستقیم به عنوان کامپایلر استفاده کرد. در این حالت «ضمنی» (implicit)، همواره از "cc" به عنوان نام کامپایلر واقعی استفاده می‌شود. این روش می‌تواند برای استفاده تعاملی در شرایطی که حالت «صریح» (explicit) کار نمی‌کند کارآمد باشد، اما برای استفاده‌های جدید واقعاً توصیه نمی‌شود.

به یاد داشته باشید که نباید همزمان از دو روش برای فراخوانی distcc استفاده کنید. اگر از دایرکتوری تغییر چهره (masquerade) استفاده می‌کنید، CC و/یا CXX را تغییر ندهید، فقط آن دایرکتوری را در ابتدای متغیر PATH خود قرار دهید. اگر از دایرکتوری masquerade استفاده نمی‌کنید، باید یا CC و/یا CXX را تغییر دهید، یا makefile(ها) را طوری ویرایش کنید که distcc را به صورت صریح فراخوانی کنند.

ایده اصلی ایجاد یک «دایرکتوری تغییر چهره» (masquerade directory) است که شامل پیوندهایی از نام کامپایلر واقعی به باینری distcc باشد. این دایرکتوری در ابتدای متغیر PATH درج می‌شود تا فراخوانی‌های کامپایلر رهگیری شده و به جای آن distcc اجرا شود. سپس distcc خود را از PATH حذف می‌کند تا کامپایلر واقعی را بیابد.

برای مثال:

# mkdir /usr/lib/distcc/bin
# cd /usr/lib/distcc/bin
# ln -s ../../../bin/distcc gcc
# ln -s ../../../bin/distcc cc
# ln -s ../../../bin/distcc g++
# ln -s ../../../bin/distcc c++

سپس، برای استفاده از distcc، کاربر تنها نیاز دارد دایرکتوری /usr/lib/distcc/bin را در ابتدای PATH قرار دهد و فهرستی از میزبان‌ها را در متغیر DISTCC_HOSTS یا در یک فایل تنظیم کند. ابزار distcc باقی کارها را مدیریت خواهد کرد.

برای شناسایی خودکار کامپایلرها و ایجاد پیوندهای نمادین تغییر چهره، اسکریپت ارائه‌شده update-distcc-symlinks را اجرا کنید.

توجه داشته باشید که این دایرکتوری تغییر چهره باید در متغیر PATH زودتر از دایرکتوری حاوی کامپایلرهای واقعیِ هم‌نام قرار گیرد، و هر برنامه کمکی که این کامپایلرها فراخوانی می‌کنند (مانند as یا ld) نیز باید در متغیر PATH در دایرکتوری بعد از دایرکتوری تغییر چهره یافت شود، زیرا distcc کامپایلر واقعی را با مقدار متغیری از PATH فراخوانی می‌کند که در آن همه دایرکتوری‌ها تا و شامل دایرکتوری تغییر چهره حذف شده‌اند.

امکان رخ دادن یک «خطای بازگشتی» (recursion error) در حالت masquerade وجود دارد، به این معنی که distcc به نوعی دوباره خود را می‌یابد، نه کامپایلر واقعی را. این خطا می‌تواند نشان‌دهنده این باشد که شما دو دایرکتوری تغییر چهره در PATH دارید، احتمالاً به دلیل وجود دو نسخه نصب‌شده distcc در مکان‌های متفاوت. همچنین می‌تواند نشان‌دهنده این باشد که شما در حال تلاش برای ترکیب عملیات «تغییر چهره‌داده» (masqueraded) و «صریح» (explicit) هستید.

می‌توان با استفاده از اسکریپت‌های شل به جای پیوندها، از خطاهای بازگشتی جلوگیری کرد. برای مثال، در /usr/lib/distcc/bin فایلی به نام cc بسازید که حاوی موارد زیر باشد:

#!/bin/sh
distcc /usr/bin/gcc "$@"

به این ترتیب، وابسته به این نیستیم که distcc مجبور باشد با بررسی متغیر PATH مکان واقعی gcc را پیدا کند. در عوض، مکان کامپایلر به طور صریح مشخص شده است.

ابزار ccache برنامه‌ای است که ساخت نرم‌افزار را با کش کردن نتایج کامپایل‌ها سرعت می‌بخشد. معمولاً ccache پیش از distcc فراخوانی می‌شود تا نتایج از یک کش معمولی بازیابی شوند. ممکن است برای makefileهای نامتعارف مقداری آزمون و خطا نیاز باشد تا همه چیز به درستی با هم کار کند.

مطمئن‌ترین روش تنظیم متغیر زیر است:

CCACHE_PREFIX="distcc"

این دستور به ccache می‌گوید که distcc را به عنوان یک پوشش (wrapper) در اطراف کامپایلر واقعی اجرا کند. ابزار ccache همچنان از کامپایلر واقعی برای تشخیص ارتقاء کامپایلر استفاده می‌کند.

سپس ccache می‌تواند با استفاده از یک دایرکتوری تغییر چهره یا با تنظیم

CC="ccache gcc"

اجرا شود.

از نسخه 2.2، ccache کامپایل حاصل از کد منبع پیش‌پردازش‌شده را کش نمی‌کند و بنابراین اگر از طریق distccd یا distcc اجرا شود، هیچ‌گاه به کش دسترسی موفق (cache hit) نخواهد داشت. این ابزار باید تنها در سمت کلاینت و پیش از distcc اجرا شود تا کارایی داشته باشد.

حالت pump در distcc با ccache سازگار نیست.

یک «فهرست میزبان» به distcc می‌گوید از کدام ماشین‌ها برای کامپایل استفاده کند. ابزار distcc به ترتیب در متغیر محیطی $DISTCC_HOSTS ، فایل $DISTCC_DIR/hosts کاربر، و فایل میزبان‌های سیستم جستجو می‌کند. اگر هیچ فهرست میزبانی یافت نشود، distcc یک هشدار صادر کرده و به صورت محلی کامپایل می‌کند.

فهرست میزبان یک فهرست ساده جداشده با فاصله (whitespace) از مشخصات میزبان‌ها است. ساده‌ترین و رایج‌ترین شکل، نام‌های میزبان است، مانند

localhost red green blue

ابزار distcc اولویت را به میزبان‌های ابتدای فهرست می‌دهد، بنابراین ماشین‌ها باید به ترتیب نزولی سرعت فهرست شوند. به ویژه، هنگامی که تنها یک کامپایل منفرد می‌تواند اجرا شود (مانند یک اسکریپت configure)، اولین ماشین فهرست‌شده به کار گرفته می‌شود (اما --randomize را در زیر ببینید).

قرار دادن localhost در نقطه مناسبی از فهرست برای دستیابی به عملکرد مناسب بسیار مهم است. از آنجا که سربار اجرای کارها به صورت محلی کم است، معمولاً localhost باید در ابتدا باشد. با این حال، مهم است که کلاینت چرخه‌های آزاد پردازنده کافی برای اجرای کارهای محلی و کلاینت distcc داشته باشد. اگر کلاینت کندتر از داوطلب‌ها باشد، یا اگر تعداد زیادی داوطلب وجود داشته باشد، کلاینت باید در انتهای فهرست قرار گیرد یا اصلاً آورده نشود. به عنوان یک قاعده کلی، اگر مجموع سرعت پردازنده کلاینت کمتر از یک‌پنجم کل باشد، کلاینت باید از فهرست کنار گذاشته شود.

اگر یک خوشه ساخت بزرگ مشترک و یک فایل میزبان مشترک دارید، قوانین بالا باعث می‌شوند چند ماشین اول در فایل میزبان‌ها اول از همه آزمایش شوند، هرچند احتمالاً شلوغ‌تر از ماشین‌های انتهای فهرست هستند. برای جلوگیری از این موضوع، کلیدواژه --randomize را در فهرست میزبان‌ها قرار دهید. این کار باعث تصادفی شدن ترتیب فهرست میزبان‌ها شده و عملکرد خوشه‌های ساخت بزرگ را اندکی بهبود می‌بخشد.

دو نام میزبان ویژه وجود دارد: --localslots و --localslots_cpp که برای تنظیم بار روی ماشین محلی مفید هستند. میزبان --localslots مشخص می‌کند چه تعداد کاری که نمی‌توانند از راه دور اجرا شوند به صورت هم‌روند روی ماشین محلی اجرا گردند، در حالی که --localslots_cpp کنترل می‌کند چه تعداد پیش‌پردازنده به صورت موازی روی ماشین محلی اجرا شوند. تنظیم دقیق این مقادیر می‌تواند کارایی را بهبود بخشد. پیونددهی (linking) در پروژه‌های بزرگ می‌تواند مقادیر زیادی از حافظه را اشغال کند. اجرای پیونددهنده‌های موازی که قابلیت اجرای راه دور ندارند، ممکن است ماشین را به استفاده از swap وادار کند که این امر عملکرد را نسبت به اجرای متوالی کارها بدون swap کاهش می‌دهد. تنظیم دقیق تعداد پیش‌پردازنده‌های موازی به شما اجازه می‌دهد فاکتورهای موازی‌سازی بزرگ‌تری با make استفاده کنید، زیرا ماشین محلی اکنون سازوکاری برای اندازه‌گیری مصرف منابع محلی در اختیار دارد.

در نهایت مدخل میزبان وجود دارد

کارایی به جزئیات کد منبع و makefileهای استفاده شده برای پروژه، و همچنین سرعت ماشین و شبکه بستگی دارد. آزمایش با تنظیمات مختلف فهرست میزبان و ضریب -j می‌تواند کارایی را بهبود بخشد.

نحو دستور به شرح زیر است:

DISTCC_HOSTS = HOSTSPEC ...
HOSTSPEC = LOCAL_HOST | SSH_HOST | TCP_HOST | OLDSTYLE_TCP_HOST
                      | GLOBAL_OPTION
                      | ZEROCONF
LOCAL_HOST = localhost[/LIMIT]
           | --localslots=<int>
           | --localslots_cpp=<int>
SSH_HOST = [USER]@HOSTID[/LIMIT][:COMMAND][OPTIONS]
TCP_HOST = HOSTID[:PORT][/LIMIT][OPTIONS]
OLDSTYLE_TCP_HOST = HOSTID[/LIMIT][:PORT][OPTIONS]
HOSTID = HOSTNAME | IPV4 | IPV6
OPTIONS = ,OPTION[OPTIONS]
OPTION = lzo | cpp | auth[=AUTH_NAME]
GLOBAL_OPTION = --randomize
ZEROCONF = +zeroconf

در اینجا چند نمونه از نحو دستور آورده شده است:

عبارت دقیق "localhost" به‌طور ویژه‌ای تفسیر می‌شود تا همگردانی‌ها به‌جای ارسال به یک دیمن روی رایانه محلی، مستقیماً اجرا شوند. اگر برای آزمایش مایل به اتصال به دیمن روی رایانه محلی هستید، نشانی IP یا نام میزبان واقعی دستگاه را وارد کنید. (این کار کُندتر خواهد بود.)
یک نشانی دقیق IPv6 محصور در کروشه، مانند [::1]
یک نشانی دقیق IPv4، مانند 10.0.0.1
نام میزبانی که با استفاده از تحلیل‌گر نام (resolver) بررسی و جستجو می‌شود.
:PORT
اتصال به یک شماره درگاه ده‌دهی مشخص‌شده، به‌جای درگاه پیش‌فرض ۳۶۳۲.
@HOSTID
اتصال به میزبان از طریق SSH، به‌جای TCP. گزینه‌های مربوط به اتصال SSH را می‌توان در ~/.ssh/config تنظیم کرد.
اتصال به میزبان از طریق SSH با نام کاربری مشخص‌شده.
:COMMAND
اتصال از طریق SSH و استفاده از مسیر مشخص‌شده برای یافتن سرور distccd. این گزینه معمولاً تنها زمانی لازم است که به دلایلی نتوانید distccd را در شاخه‌ای درون PATH پیش‌فرض اتصالات SSH نصب کنید. اگر در حالت SSH خطاهایی مانند "distccd: command not found" دریافت کردید از این گزینه استفاده نمایید.
/LIMIT
یک حد ده‌دهی را می‌توان به هر مشخصه میزبان اضافه کرد تا تعداد کارهایی که این کلاینت به دستگاه ارسال می‌کند محدود شود. مقدار این حد به‌طور پیش‌فرض چهار به‌ازای هر میزبان (دو برای localhost) است، اما ممکن است توسط سرور بیشتر محدود شود. فقط برای سرورهایی با بیش از دو پردازنده نیاز به افزایش این مقدار خواهید داشت.
,lzo
فشرده‌سازی LZO را برای این میزبان TCP یا SSH فعال می‌کند.
,cpp
حالت distcc-pump را برای این میزبان فعال می‌کند. نکته: دستور ساخت باید درون اسکریپت pump اجرا شود تا سرور include راه‌اندازی گردد.
,auth
احراز هویت متقابل مبتنی بر GSSAPI را برای این میزبان فعال می‌کند.
نام استاندارد (canonical) مورد استفاده برای نام ارشد سرویس (service principal name) به‌جای HOSTNAME (یا fqdn متناظر آن). این گزینه در صورت دسترسی به یک سرور احرازهویت‌شده از طریق هدایت درگاه ssh مفید است؛ در این حالت HOSTNAME برابر 127.0.0.1 خواهد بود.
تصادفی‌سازی ترتیب فهرست میزبان‌ها پیش از اجرا.
+zeroconf
این گزینه تنها در صورتی در دسترس است که distcc در زمان پیکربندی با پشتیبانی فعال از Avahi همگردانی شده باشد. هنگامی که این مدخل ویژه در فهرست میزبان‌ها موجود باشد، distcc از کشف سرویس Avahi Zeroconf DNS (DNS-SD) برای یافتن سرورهای distccd در دسترس در شبکه محلی استفاده خواهد کرد. این ویژگی نیاز به درج صریح نام‌های میزبان یا نشانی‌های IP دستگاه‌های سرور distcc را برطرف می‌کند. سرورهای distccd باید با گزینه "--zeroconf" در distccd راه‌اندازی شده باشند. یک نکته مهم این است که در پیاده‌سازی فعلی، حالت pump (گزینه ",cpp") و فشرده‌سازی (گزینه ",lzo") هرگز برای میزبان‌های یافته‌شده از طریق zeroconf به کار نخواهند رفت.

در اینجا مثالی برای نمایش برخی احتمالات آورده شده است:

localhost/2 @bigman/16:/opt/bin/distccd oldmachine:4200/1
# cartman is down
distant/3,lzo

درج توضیحات (کامنت‌ها) در مشخصات میزبان مجاز است. توضیحات با نماد هش/پوند (#) آغاز می‌شوند و تا پایان سطر ادامه دارند.

اگر میزبانی در فهرست در دسترس نباشد، distcc هشداری صادر کرده و آن میزبان را به‌مدت حدود یک دقیقه نادیده می‌گیرد.

گزینه میزبانی lzo مشخص می‌کند که فشرده‌سازی LZO باید برای انتقال داده‌ها، شامل کد مبدأ پیش‌پردازش‌شده، کد شیء (object code) و پیام‌های خطا استفاده شود. فشرده‌سازی معمولاً در شبکه‌های کُندتر از 100Mbps به‌صرفه است، اما نتایج بسته به شبکه، پردازنده‌ها و درخت کد مبدأ ممکن است متغیر باشد.

فعال کردن فشرده‌سازی موجب می‌شود کلاینت و سرور distcc از زمان CPU بیشتری استفاده کنند، اما ترافیک شبکه کاهش یابد. زمان اضافه پردازنده برای حالت pump ناچیز است. نسبت فشرده‌سازی معمولاً ۴:۱ برای کد مبدأ و ۲:۱ برای کد شیء است.

استفاده از فشرده‌سازی نیازمند آن است که هم کلاینت و هم سرور دست‌کم از نسخه 2.9 نرم‌افزار distcc استفاده کنند. نیازی به پیکربندی سرور نیست: سرور همواره به درخواست‌های فشرده‌شده با پاسخ‌های فشرده پاسخ می‌دهد.

حالت pump نیازمند فعال بودن گزینه میزبانی lzo در سرورها است.

اگر نام همگردان یک مسیر مطلق باشد، بدون تغییر به سرور تحویل داده شده و همگردان از همان شاخه اجرا می‌شود. برای مثال:

distcc /usr/local/bin/gcc-3.1415 -c hello.c

اگر نام همگردان مطلق نبوده یا به‌طور کامل واجد شرایط نباشد، متغیر PATH در distccd جستجو می‌شود. هنگامی که distcc از یک شاخه تغییر چهره (masquerade) اجرا شود، تنها نام پایه همگردان استفاده خواهد شد. متغیر PATH کلاینت فقط برای اجرای پیش‌پردازنده به کار می‌رود و هیچ اثری بر مسیرهای سرور ندارد.

هر دو کلاینت و سرور distcc برای انتقال داده روی شبکه، مهلت‌های زمانی اعمال می‌کنند. هدف از این کار تشخیص میزبان‌هایی است که از کار افتاده‌اند یا غیرقابل‌دسترس هستند، و نیز جلوگیری از معلق ماندن نامحدود کامپایل‌ها در صورتی که سرور در حین استفاده قطع شود. اگر مهلت زمانی سمت کلاینت منقضی شود، کار مجدداً به‌طور محلی اجرا خواهد شد.

مهلت زمانی انتقال داده در حال حاضر قابل‌پیکربندی نیست. مهلت زمانی تشخیص کارهای توزیع‌شدهٔ راکد از طریق متغیر محیطی DISTCC_IO_TIMEOUT قابل‌پیکربندی است.

پیام‌های خطا یا هشدارهای کامپایلرهای محلی یا دوردست به خروجی عیب‌یابی در کلاینت هدایت می‌شوند.

ابزار distcc می‌تواند در صورت استفاده از گزینهٔ verbose، اطلاعات اشکال‌زدایی جامعی ارائه دهد. این رفتار توسط متغیر محیطی DISTCC_VERBOSE در سمت کلاینت و گزینهٔ --verbose در سمت سرور کنترل می‌شود. برای عیب‌یابی، پیام‌های خطای هر دو سمت کلاینت و سرور را بررسی کنید.

کد خروج distcc معمولاً همان کد خروج کامپایلر است: صفر برای کامپایل موفقیت‌آمیز و غیرصفر در غیر این صورت.

ابزار distcc میان خطاهای «واقعی» نظیر خطای نحوی در کد منبع، و خطاهای «اتفاقی» مانند مشکل شبکه در اتصال به یک داوطلب تمایز قائل می‌شود. در صورت بروز خطاهای اتفاقی، distcc کامپایل را به‌صورت محلی مجدداً امتحان خواهد کرد، مگر اینکه گزینهٔ DISTCC_FALLBACK غیرفعال شده باشد.

اگر کامپایلر با یک سیگنال خارج شود، distcc کد خروجی برابر با ۱۲۸ به علاوهٔ شمارهٔ سیگنال برمی‌گرداند.

خطاهای داخلی distcc موجب ایجاد کد خروجی بین ۱۰۰ تا ۱۲۷ می‌شوند؛ به‌ویژه:

100
خطای عمومی distcc.
101
آرگومان‌های نادرست.
102
شکست در bind.
103
شکست در اتصال (Connect).
104
فروپاشی کامپایلر (Compiler crashed).
105
کمبود حافظه.
106
مشخصات نامعتبر میزبان (Bad Host SPEC).
107
خطای I/O.
108
دادهٔ ناقص یا کوتاه‌شده (Truncated).
109
خطای پروتکل (Protocol Error).
110
کامپایلر مشخص‌شده روی میزبان دوردست یافت نشد. بررسی کنید که $CC به درستی تنظیم شده باشد و در پوشه‌ای روی مسیر جستجوی (search path) مربوط به distccd نصب شده باشد.
111
فراخوانی بازگشتی به distcc.
112
شکست در کنار گذاشتن دسترسی‌ها (Failed to discard privileges).
113
دسترسی شبکه رد شد (Network access denied).
114
در حال استفاده توسط فرایندی دیگر.
115
چنین فایلی وجود ندارد (No such file).
116
هیچ میزبانی تعریف نشده و بازگشت به محلی (fallbacks) غیرفعال است.
118
پایان مهلت زمانی (Timeout).
119
سامانه GSS-API - کد خطای کلی برای خطاهای مرتبط با GSS-API.
120
فراخوانی‌شده برای پیش‌پردازش، که باید به‌صورت محلی انجام شود.

اگر $DISTCC_HOSTS تنظیم نشده باشد، distcc فهرست میزبان‌ها را از $DISTCC_DIR/hosts یا یک فایل پیکربندی سراسری سیستم که در زمان کامپایل تنظیم شده می‌خواند. مکان فایل‌ها در خروجی distcc --help نشان داده شده است.

ابزار distcc تعدادی فایل موقت و فایل قفل را در زیرشاخهٔ دایرکتوری موقت ایجاد می‌کند.

رفتار distcc توسط تعدادی متغیر محیطی کنترل می‌شود. برای بیشتر موارد، اگر فهرست میزبان‌ها در یک فایل ذخیره شده باشد نیازی به تنظیم مقداری نیست.

فهرست مشخصات میزبان‌های داوطلب که با فاصله از هم جدا شده‌اند.
اگر روی 1 تنظیم شود، distcc پیام‌های توضیحی را روی جریان خطای استاندارد یا در فایل لاگ تولید می‌کند. این ویژگی می‌تواند در اشکال‌زدایی مشکلات مفید باشد. گزارش‌های اشکال باید شامل خروجی پرگو (verbose) باشند.
فایل لاگ برای دریافت پیام‌ها از خود distcc، به جای stderr.
به‌طور پیش‌فرض اگر distcc در توزیع یک کار به ماشین مورد نظر ناموفق باشد، یا اگر هیچ فهرست میزبانی یافت نشود، کار را به‌صورت محلی کامپایل خواهد کرد. اگر این متغیر روی 0 تنظیم شود، بازگشت به محلی غیرفعال شده و آن کامپایل‌ها صرفاً با شکست مواجه خواهند شد. توجه داشته باشید که این متغیر بر کارهایی که همیشه باید محلی باشند مانند پیوند دادن (linking) تأثیری ندارد.
به‌طور پیش‌فرض distcc فراخوانی‌های gcc را برای استفاده از نام‌های کاملاً واجد شرایط (مانند x86_64-linux-gnu-gcc) و clang را برای استفاده از گزینهٔ -target بازنویسی می‌کند. تنظیم این متغیر این قابلیت را غیرفعال می‌کند.
مشخص می‌کند که distcc پس از مواجهه با شکست کامپایل روی یک سرور کامپایل خاص، چه مدت (به ثانیه) از تلاش برای استفاده از آن سرور خودداری می‌کند. به‌طور پیش‌فرض روی 60 ثانیه تنظیم شده است. برای غیرفعال کردن کامل این رفتار، آن را روی 0 تنظیم کنید.
مشخص می‌کند که distcc قبل از تصمیم‌گیری دربارهٔ اینکه یک کار توزیع‌شده دچار وقفهٔ زمانی شده است، چه مدت (به ثانیه) منتظر بماند. اگر انتظار می‌رود یک کار توزیع‌شده زمان زیادی ببرد، افزایش این مقدار را در نظر بگیرید تا مهلت زمانی کار سپری نشود و به کامپایل محلی سقوط نکند. به‌طور پیش‌فرض روی 300 ثانیه تنظیم شده است.
مشخص می‌کند هنگامی که تمامی سرورهای کامپایل در حال استفاده هستند، distcc چه مدت (به میلی‌ثانیه) مکث کند. به‌طور پیش‌فرض روی 1000 میلی‌ثانیه (۱ ثانیه) تنظیم شده است. تنظیم این مقدار روی عددی کوچک‌تر (مانند 10 میلی‌ثانیه) ممکن است توان عملیاتی را برای برخی پیکربندی‌ها بهبود بخشد، به قیمت افزایش بار پردازنده روی ماشین کلاینت distcc.
اگر روی 1 تنظیم شود، فایل‌های موقت پس از استفاده حذف نمی‌شوند. برای اشکال‌زدایی یا زمانی که دیسک‌های شما بسیار خالی هستند مناسب است.
اگر روی 0 تنظیم شود، استفاده از «TCP cork» را حتی در صورت وجود روی سیستم غیرفعال می‌کند. استفاده از cork معمولاً کمک می‌کند تا درخواست‌ها در بسته‌های کمتری فشرده شوند و کارایی را افزایش می‌دهد. این گزینه معمولاً باید فعال بماند.
دستور مورد استفاده برای برقراری اتصالات SSH را مشخص می‌کند. پیش‌فرض "ssh" است اما می‌تواند به دستور اتصال دیگری نظیر "lsh" یا "tsocks-ssh" که خط فرمان مشابهی را می‌پذیرد تغییر یابد. این دستور به کلمات مجزا تقسیم نمی‌شود و از طریق شل اجرا نمی‌گردد.
در صورت تنظیم، هنگامی که یک کامپایل دوردست با شکست مواجه شود، distcc دیگر تلاش نخواهد کرد تا آن فایل را به‌طور محلی بازکامپایل کند.
دایرکتوری پیکربندی به ازای هر کاربر برای ذخیرهٔ فایل‌های قفل و وضعیت. به‌طور پیش‌فرض ~/.distcc/ استفاده می‌شود.
دایرکتوری برای فایل‌های موقت نظیر خروجی پیش‌پردازنده. به‌طور پیش‌فرض /tmp/ استفاده می‌شود.
در صورت تنظیم و در صورتی که DISTCC_LOG تنظیم نشده باشد، خطاهای distcc در توصیف‌کننده فایل مشخص‌شده توسط این متغیر نوشته می‌شوند. این متغیر عمدتاً برای استفادهٔ خودکار توسط ccache در نظر گرفته شده است، تا از ذخیره در حافظهٔ موقت (caching) خطاهای گذرا مانند مشکلات شبکه جلوگیری کند.
اگر تنظیم شود، distcc هنگامی که کامپایل در میزبان دوردست شکست خورده اما به‌صورت محلی موفقیت‌آمیز باشد، یک ایمیل ارسال می‌کند. روش‌های اکتشافی درونی مانع ارسال برخی ایمیل‌های مغایرت می‌شوند اگر مشکل ناشی از تغییر فایل محلی میان کامپایل ناموفق دوردست و کامپایل موفق محلی باشد.
حداکثر تعداد مجاز شکست کامپایل دوردست در حالت pump، پیش از آنکه distcc به حالت عادی distcc تغییر وضعیت دهد. به‌طور پیش‌فرض روی 1 تنظیم شده است.
نشانی رایانامه برای رایانامه‌های ناهمخوانی؛ مقدار پیش‌فرض "distcc-pump-errors" است.
در صورت تنظیم، نام principal که distccd تحت آن اجرا می‌شود را مشخص می‌کند و برای احراز هویت سرور نزد کلاینت به کار می‌رود. این متغیر محیطی تنها زمانی استفاده می‌شود که distcc با گزینه پیکربندی --with-auth کامپایل شده باشد و گزینه میزبان ,auth مشخص شده باشد.

کامپایل متقاطع به معنای ساخت برنامه‌ها برای اجرا روی دستگاهی با پردازنده، معماری یا سیستم‌عامل متفاوت نسبت به محل کامپایل آن‌ها است. distcc از کامپایل متقاطع، از جمله گروه‌هایی از دستگاه‌های با معماری‌های ناهمگون پشتیبانی می‌کند، هرچند ممکن است برخی تغییرات در دستورهای کامپایل لازم باشد.

دستور کامپایل ارسال‌شده به distcc باید به گونه‌ای باشد که روی هر دستگاه داوطلب به‌درستی اجرا شده و یک پرونده شیء (object file) از نوع مناسب تولید کند. اگر دستگاه‌ها پردازنده‌های متفاوتی داشته باشند، صرفاً استفاده از distcc cc احتمالاً کار نخواهد کرد، زیرا این کار به‌طور معمول کامپایلر بومی دستگاه داوطلب را فراخوانی می‌کند.

دستگاه‌هایی با پردازنده یکسان اما سیستم‌های عامل متفاوت لزوماً پرونده‌های .o سازگار تولید نمی‌کنند.

چندین پیکربندی مختلف از gcc می‌توانند در کنار یکدیگر روی هر دستگاهی نصب شوند. اگر gcc را از کد منبع می‌سازید، باید از گزینه‌های پیکربندی --program-suffix استفاده کنید تا با نامی نصب شود که نسخه gcc و پلتفرم مقصد را کدگذاری کرده باشد.

قاعده نام‌گذاری توصیه‌شده برای gcc به‌صورت TARGET-gcc-VERSION است، مانند i686-linux-gcc-3.2 . نگارش ۳.۳ از GCC علاوه بر TARGET-gcc و در صورت بومی بودن، gcc-VERSION و gcc تحت این نام نیز نصب می‌شود.

کامپایلر باید با نامی یکسان روی کلاینت و روی تک‌تک دستگاه‌های داوطلب نصب شده باشد.

اگر فکر می‌کنید اشکالی در distcc یافته‌اید، لطفاً پرونده reporting-bugs.txt در شاخه مستندات را برای دریافت اطلاعات درباره نحوه گزارش آن مشاهده کنید.

برخی makefileها دارای وابستگی‌های گمشده یا اضافی هستند که باعث ساخت موازی نادرست یا کند می‌شوند. فراخوانی بازگشتی make ناکارآمد است و می‌تواند پردازنده‌ها را بی‌دلیل برای مدت‌های طولانی بیکار بگذارد. (مطلب Recursive Make Considered Harmful نوشته Peter Miller را ببینید.) اشکالات Makefile رایج‌ترین دلیل شکست در ساخت درخت‌های کد تحت distcc هستند. جایگزین‌های Make مانند SCons می‌توانند در برخی پروژه‌ها فرایند ساخت بسیار سریع‌تری فراهم کنند.

استفاده از نسخه‌های مختلف gcc می‌تواند باعث بروز مشکلات گیج‌کننده در ساخت شود، زیرا پرونده‌های سرایند و رابط‌های باینری در طول زمان تغییر کرده‌اند و برخی توزیع‌کنندگان وصله‌های ناسازگار را بدون تغییر شماره نسخه اضافه کرده‌اند. distcc در برابر استفاده از نسخه‌های ناسازگار محافظتی نمی‌کند. خطاهای کامپایلر درباره مشکلات پیوند (link) یا اعلانات در پرونده‌های سرایند سیستم، معمولاً به دلیل ناهماهنگی یا نصب نادرست کامپایلرها رخ می‌دهند.

گزینه -MD در gcc در صورتی که پرونده‌های منبع و پرونده‌های شیء در شاخه‌های متفاوتی قرار داشته باشند و از گزینه -MF استفاده نشود، می‌تواند خروجی را در شاخه اشتباهی تولید کند. به دلیل تغییرات ناسازگار میان نسخه‌های gcc هیچ راه‌حل کاملی وجود ندارد. مشخص کردن صریح پرونده خروجی وابستگی با -MF این مشکل را برطرف می‌کند.

اتصالات حالت TCP فقط باید در شبکه‌های مورد اعتماد استفاده شوند.

گنجاندن دستگاه‌های کند در فهرست میزبان‌های داوطلب می‌تواند سرعت ساخت را کاهش دهد.

هنگامی که distcc یا ccache روی NFS استفاده می‌شود، سیستم پرونده باید با گزینه no_subtree_check صادر (export) شود تا تغییر نام قابل اعتماد بین شاخه‌ها امکان‌پذیر باشد.

می‌توان کامپایلر را با خط فرمان gcc hello.c برای انجام هم‌زمان کامپایل و پیوند فراخوانی کرد. distcc این دستور را به بخش‌های جداگانه تقسیم نمی‌کند، بلکه کل آن را به‌صورت محلی اجرا می‌کند.

حالت distcc-pump برای پرونده‌های منبعی که شامل include با مسیرهای مطلق هستند (چه به‌طور مستقیم یا در یک پرونده includeشده)، به حالت distcc معمولی بازمی‌گردد.

به دلیل محدودیت‌های موجود در gcc، برنامه gdb در برخی شرایط ممکن است نتواند به‌طور خودکار پرونده‌های منبع را برای برنامه‌های ساخته‌شده با distcc پیدا کند. می‌توان از دستور directory در gdb استفاده کرد. برای حالت معمولی (غیر pump) distcc، این موضوع در gcc 3.4 و نگارش‌های بعدی برطرف شده است. برای حالت pump، اصلاحیه gcc 3.4 کافی نیست؛ ما این محدودیت gcc را با بازنویسی پرونده‌های شیء تولیدشده توسط gcc دور زده‌ایم، اما این کار تنها برای پرونده‌های شیء ELF انجام می‌شود و نه برای سایر قالب‌های پرونده شیء.

پرونده‌های .o تولیدشده توسط distcc در حالت pump با پرونده‌های تولیدشده به‌صورت محلی تفاوت خواهند داشت: برای پرونده‌های غیر ELF، اطلاعات اشکال‌زدایی شاخه‌های کامپایل سرور را مشخص خواهند کرد. خود کد باید یکسان باشد.

برای قالب ELF، برنامه distcc پرونده‌های .o را بازنویسی می‌کند تا اطلاعات مسیر شاخه کامپایل تصحیح شود. گرچه پرونده‌های .o حاصل از نظر بایتی با آنچه با کامپایل روی کلاینت محلی تولید می‌شد یکسان نیستند (به دلیل فاصله‌گذاری‌های متفاوت و غیره)، اما از نظر عملکردی باید همتا باشند.

در حالت distcc-pump، سرور include قادر به مدیریت برخی includeهای محاسباتی بسیار پیچیده (مانند آنچه در بخش‌هایی از کتابخانه Boost وجود دارد) نیست. سرور include دچار اتمام مهلت زمانی (timeout) می‌شود و distcc به حالت معمولی بازمی‌گردد.

در حالت distcc-pump، فرض بر این است که پرونده‌های منبع و سرایند در طول فرایند ساخت تغییر نمی‌کنند. بحث موجود در بخش DISTCC DISCREPANCY SYMPTOMS از include_server(1(). را ببینید.

سایر اشکالات شناخته‌شده ممکن است در http://code.google.com/p/distcc/ مستند شده باشند.

ابزار distcc توسط Martin Pool <mbp@sourcefrog.net> با همکاری افراد و پژوهشگران متعددی از جمله Wayne Davison، Frerich Raabe، Dimitri Papadopoulos و دیگر کسانی که نامشان در پرونده NEWS آمده، نوشته شده است. لطفاً اشکالات را به <distcc@lists.samba.org> گزارش کنید. برای آگاهی از نویسندگان حالت پمپ به pump(1) مراجعه نمایید.

استفاده از distcc برای همگان آزاد است. برنامه distcc (از جمله این راهنما) تنها تحت شرایط «مجوز عمومی همگانی گنو» (GNU General Public Licence) نسخه ۲ یا بالاتر قابل رونوشت‌برداری، ویرایش یا توزیع می‌باشد. ابزار distcc بدون هیچ‌گونه ضمانتی ارائه می‌شود. نسخه‌ای از پروانه GPL در پرونده COPYING قرار گرفته است.

distccd(1)، pump(1)، include_server(1)، gcc(1)، make(1) و ccache(1). http://code.google.com/p/distcc/ https://ccache.dev/

9 June 2008