makepp_build_check - آنلاین در ابر

برنامه:

نام

makepp_build_check -- چگونه makepp تصمیم به بازسازی فایل ها می گیرد

شرح

A: "مستقل_معماری"، E: "مطابقت کامل"، I: "عمل_غیره"، O: "only_action"،
T: "هدف_جدیدتر"

Makepp اطلاعات مختلفی را در مورد نحوه ساخت آخرین بار یک فایل خاص ذخیره می کند.
این اطلاعات شامل دستور ساخت، معماری و امضای همه است
وابستگی های فایل (تمام اطلاعات ذخیره شده در زیر شاخه است .makepp of
هر دایرکتوری.) اگر هر یک از این اطلاعات تغییر کرده باشد، makepp معمولا تصمیم می گیرد
فایل را بازسازی کنید روش بررسی ساخت همان چیزی است که تصمیم makepp برای بازسازی را کنترل می کند.
تصمیم می گیرد که به کدام اطلاعات نگاه کند و کدام را نادیده بگیرد.

Makepp معمولاً روش صحیح بررسی ساخت را به طور خودکار انتخاب می کند. با این حال، شما می توانید
با استفاده از :build_check modifier روی یک قانون، روش امضا را تغییر دهید
قانون یا برای همه قوانین موجود در یک makefile با استفاده از عبارت build_check یا برای همه
با استفاده از گزینه خط فرمان -m یا --build-check-method به یکباره makefiles را ایجاد کنید.

داده‌هایی که برای تصمیم‌گیری در مورد بازسازی یا مخزن یا ساخت حافظه پنهان استفاده می‌شوند در آن ذخیره می‌شوند
فایل اطلاعات ساخت داخلی می توانید آن را با makeppinfo، mppi نمایش دهید. زیر هر کدام
متد مثالی از نحوه دیدن کلیدهای آن ارائه می دهد.

ساختن بررسی روش مشمول in la توزیع
در حال حاضر، پنج روش بررسی ساخت در توزیع وجود دارد:

مطابقت کامل
این روش از تاریخ های اصلاح روی فایل به عنوان امضا استفاده می کند. آن را بازسازی می کند
اهداف، مگر اینکه همه شرایط زیر درست باشد:

· امضای هر وابستگی همان است که در ساخت قبلی بود.

· امضای هر هدف همان است که در ساخت قبلی بود (یعنی هیچ کس
از زمانی که makepp آنها را ساخته است، با اهداف به هم ریخته است).

· دستور ساخت تغییر نکرده است.

· معماری ماشین (یا آنچه پرل فکر می کند) تغییر نکرده است.

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

· اگر با ساخت سنتی کامپایل کرده اید، و سپس به makepp بروید،
اولین باری که makepp را اجرا می کنید همه چیز دوباره کامپایل می شود.

· اگر به اطلاعات makepp در مورد آنچه در آخرین بیلد رخ داده آسیب بزنید (به عنوان مثال،
دایرکتوری فرعی ".makepp" را حذف می کنید، یا وقتی همه چیز را کپی می کنید، آن را کپی نمی کنید
else)، سپس یک بازسازی آغاز می شود.

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

· اگر فایلی را خارج از کنترل makepp تغییر دهید (به عنوان مثال، شما
دستور compilation را خودتان انجام دهید)، سپس makepp دفعه بعد فایل را بازسازی می کند. (اگر
می‌خواهید از این امر جلوگیری کنید، گزینه خط فرمان "--dont-build" را بررسی کنید.)

· فایل‌های مستقل از معماری زمانی که به فایل دیگری تغییر می‌کنید، بازسازی می‌شوند
معماری. این معمولاً مشکلی نیست، زیرا اغلب زمان زیادی نمی برد
ساختن. دلیل اینکه همه فایل ها به جای برچسب با معماری برچسب گذاری می شوند
فقط فایل های باینری، این است که اغلب اوقات حتی فایل های ASCII نیز معماری هستند.
وابسته به عنوان مثال، خروجی از برنامه Solaris "lex" کامپایل نمی شود
لینوکس (یا حداقل آخرین باری که آن را امتحان کردم این درست بود).

به طور مشخص، یک فایل بازسازی نمی شود، یا می توان آن را از مخزن یا بیلد دریافت کرد.
حافظه پنهان، اگر خروجی دستور زیر ثابت بماند، یعنی با امضاهای آن مطابقت داشته باشد
وابستگی ها:

فایل mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S'

معماری_مستقل
روش "معماری_مستقل" همان "exact_match" است با این تفاوت که این کار را انجام می دهد
معماری را بررسی نکنید این می تواند برای فایل های مستقل از معماری مفید باشد،
وقتی به معماری دیگری تغییر می‌دهید، نیازی به بازسازی ندارند. برای
به عنوان مثال، اگر قبلاً آن را اجرا کرده اید، احتمالاً نیازی به اجرای مجدد "bison" در Solaris ندارید
لینوکس است.

روش "معماری_مستقل" بهتر است با مشخص کردن آن با استفاده از
اصلاح کننده ":build_checkarchitecture_independent" برای هر قانون تولید شده
فایل های مستقل معماری Makepp به طور پیش فرض هرگز هیچ فایلی را فرض نمی کند
معماری مستقل، زیرا حتی .c فایل ها می توانند وابسته به معماری باشند. برای
به عنوان مثال، خروجی Solaris lex تحت لینوکس یا حداقل آن کامپایل نخواهد شد
آخرین باری که سعی کردم بنابراین باید به صورت دستی این روش بررسی ساخت را برای آن مشخص کنید
هر فایلی که واقعاً مستقل از معماری باشد.

به طور مشخص، یک فایل بازسازی نمی شود، یا می توان آن را از مخزن یا بیلد دریافت کرد.
حافظه پنهان، اگر خروجی دستور زیر ثابت بماند، یعنی با امضاهای آن مطابقت داشته باشد
وابستگی ها:

mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S' فایل

ignore_action
روش "ignore_action" همان "exact_match" است با این تفاوت که بررسی نمی کند
رشته عمل (فرمان). گاهی اوقات یک فرمان می تواند تغییر کند و شما نمی خواهید
مجبور به بازسازی

برای مثال، ممکن است بخواهید صریحاً تاریخی را در دستور خود قرار دهید تا زمانی که
ساخت انجام شد، اما نمی‌خواهید هر بار که دستور انجام می‌شود، بازسازی را مجبور کنید
اجرا شده. مثلا،

BUILD_DATE := $(تاریخ پوسته)

my_program : $(MODULES).o
$(CXX) $(ورودی ها) -DBUILD_DATE="\"$(BUILD_DATE)\"" date_stamp.c -o $(خروجی)

این کامپایل خواهد شد date_stamp.c با آخرین مهر تاریخ ساخت، اما a را مجبور نمی کند
وقتی تاریخ تغییر کرد دوباره کامپایل کنید. متاسفانه، اگر چیز دیگری در مورد لینک
فرمان تغییر می کند (به عنوان مثال، شما گزینه های پیوند دهنده را تغییر می دهید)، همچنین باعث ایجاد مجدد نمی شود.

این همچنین در رابطه با $(changed_inputs) یا $ مفید است؟ متغیر برای
اقداماتی که صرفاً یک هدف را به روز می کنند، نه اینکه آن را از ابتدا بازسازی کنند. برای
به عنوان مثال، می توانید یک فایل .a مانند این را به روز کنید:

libmine.a: *.o: build_check ignore_action
$(AR) ru $(خروجی) $(changed_inputs)

اگر فراموش کنید ": build_check" را مشخص کنید، این باز هم بیشتر کار می کند
ignore_action". با این حال، فرض کنید هیچ یک از فایل های .o تغییر نکرده است. دستور
اکنون "ar ru libmine.a" خواهد بود که احتمالاً با آنچه دفعه قبل بود متفاوت است
(به عنوان مثال، "ar ru libmine.a buggy_module.o")، بنابراین makepp دستور را اجرا خواهد کرد. در این
در این صورت، فرمان کاری جز اتلاف وقت انجام نمی دهد.

ساختن فایل‌های .a مانند این ممنوع است، زیرا می‌تواند فایل‌های .o را در داخل باقی بگذارد
آرشیو اگر یک فایل منبع را حذف کنید، فایل .o همچنان داخل فایل .a است،
و این می تواند منجر به ساخت نادرست شود. بهتر است یک فایل . مانند این بسازید:

libmine.a : *.o
&rm $(خروجی)
$(AR) ru $(خروجی) $(ورودی ها)

به طور مشخص، یک فایل بازسازی نمی شود، یا می توان آن را از مخزن یا بیلد دریافت کرد.
حافظه پنهان، اگر خروجی دستور زیر ثابت بماند، یعنی با امضاهای آن مطابقت داشته باشد
وابستگی ها:

فایل mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_{DEP,VAL}S'

target_جدیدتر
روش "target_newer" فقط به تاریخ فایل نگاه می کند. اگر هر وابستگی بیشتر باشد
اخیر از هدف، هدف بازسازی شده است. این الگوریتمی است که
یونیکس سنتی ساخت استفاده های سودمند

روش "target_newer" به اندازه روش "exact_match" ایمن نیست زیرا اینطور نیست
اگر دستور ساخت را تغییر دهید، یا اگر فایلی را با یک جایگزین کنید، یک بازسازی را آغاز کنید
نسخه قدیمی تر گاهی اوقات اگر ساعت ها درست نباشند، ممکن است گیج شود
هماهنگ شده به عنوان مثال، اگر یک فایل به نحوی تاریخ 4 ژوئن 2048 را دریافت کند، پس
از هم اکنون تا سال 2048، هر فایلی که به آن فایل وابسته است، بازسازی خواهد شد
فایل تغییر نمی کند همچنین جابجایی به معماری متفاوت باعث ایجاد a نمی شود
بازسازی کنید. از واکشی هدف یک قانون از کش ساخت جلوگیری می کند، زیرا وجود ندارد
امضای منحصربه‌فردی که می‌تواند به مجموعه بی‌پایانی از جفت‌ها مرتبط شود
رابطه جدیدتر از

اما چند مورد وجود دارد که ممکن است بخواهید از روش "target_newer" استفاده کنید:

· زمانی که برای کاربر منطقی است که فایلی خارج از کنترل makepp بسازد.
شاید رایج ترین مثال دستوراتی باشد که makefile را تولید می کند
خود، یعنی رویه پیکربندی خودکار. کاربران معمولاً پیکربندی را صادر می کنند
به صورت دستی فرمان دهید، اما فایل‌های makefi اغلب راهی برای به‌روزرسانی خود دارند
بطور خودکار. در این مورد، ما نمی‌خواهیم فایل را مجبور به بازسازی کنیم
خود اگر کاربر دستور را به صورت دستی تایپ کرده باشد، روش "target_newer" است
مناسب تر از روش "exact_match" است. در واقع، اگر makepp در تلاش است
یک makefile بسازید، تا زمانی که تمام شود، "target_newer" را به روش پیش فرض تبدیل می کند
ساختن پرونده

· وقتی برای کاربر منطقی است که یک فایل را پس از ساخت makepp تغییر دهد. برای
برای مثال، اگر فایلی وجود ندارد، ممکن است بخواهید آن را از یک مرکز کپی کنید
مکان، یا آن را از یک مخزن بررسی کنید. اما کاربر باید اجازه داشته باشد
آن را اصلاح کنید. اگر از روش پیش‌فرض بررسی ساخت «exact_match» استفاده می‌کنید، makepp این کار را انجام می‌دهد
تشخیص دهید که کاربر فایل را تغییر داده است و بنابراین یک کپی جدید از آن را مجبور می کند
مکان مرکزی یا یک تسویه حساب تازه، که تغییرات کاربر را پاک می کند.

اگر نیاز دارید که مُهرهای زمانی را به صورت دستی بررسی کنید، به مثال‌های makeppinfo برای نحوه دریافت مراجعه کنید
مسیر هر وابستگی

only_action
روش بسیار خاص "only_action" تنها در صورتی عمل را اجرا می کند که دستور داده شود
رشته با آخرین باری که اجرا شد متفاوت است. مثلا،

$(ROOT)/include/%.h : %.h
&ln -fr $(ورودی) $(خروجی)

فایلی را منتشر می کند، اما وقتی فایل تغییر می کند این کار را تکرار نمی کند. توجه داشته باشید که &ln
دستور تعبیه شده است و بنابراین ارزان است، اما makepp هنوز باید a را قطع و نظارت کند
فرآیند برای انجام کل عمل بنابراین اگر فایل های زیادی برای انتشار دارید، وجود دارد
هنوز یک فایده است در واقع ما روش را مشخص نکردیم، زیرا، زمانی که هدف
یک پیوند نمادین است، این چک ساخت به طور خودکار استفاده می شود. شما فقط نیاز دارید
آن را برای دستورات دیگری که صرفاً به دستور بستگی دارد (که معمولاً
شامل نام ورودی ها است:

%.list: %.x: build_check only_action
&echo $(ورودی ها) -o $(خروجی)

به طور مشخص، یک فایل بازسازی نمی شود، یا می توان آن را از مخزن یا بیلد دریافت کرد.
حافظه پنهان، اگر خروجی دستور زیر ثابت بماند، یعنی با امضاهای آن مطابقت داشته باشد
وابستگی ها:

فایل mppi -kCOMMAND

روش های دیگر بررسی ساخت امکان پذیر است. شما می توانید روش بررسی ساخت خود را بنویسید
ایجاد یک ماژول "Mpp::BuildCheck::MyMethod". مستندات را در
Mpp/BuildCheck.pm در توزیع makepp. به احتمال زیاد، شما چک ساخت خود را می خواهید
روش ارث بردن از "Mpp::BuildCheck::exact_match"، بنابراین مستندات آن را نیز بخوانید.

معمولاً تغییر مکانیسم امضا مفیدتر از اصلاح بررسی ساخت است
مکانیزم به طور مستقیم قبل از اینکه مکانیسم بررسی ساخت را تغییر دهید، ببینید آیا مشکل شماست
با تغییر امضاها بهتر است (برای جزئیات به makepp_signatures مراجعه کنید).

در اینجا دلایلی وجود دارد که چرا یک روش بررسی ساخت سفارشی ممکن است مفید باشد:

· اگر می خواهید makepp بخشی از دستور را نادیده بگیرد. مثلا اگر دستوراتی دارید
در میکاپ شما به این صورت:

x.o: x.c
ssh $(REMOTE_MACHINE) سی سی $< -o $@

اگر "$(REMOTE_MACHINE)" تغییر کند، ممکن است بخواهید makepp مجبور به بازسازی نشود. شما
می تواند روش "exact_match" را تغییر دهد تا از دستورات ssh مطلع شود و دستورات را نادیده بگیرد.
نام ماشین برای رسیدن به این هدف، :ارسال کنید.

با استفاده از خدمات onworks.net از makepp_build_check به صورت آنلاین استفاده کنید