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

برنامه:

نام

makepp_cookbook - بهترین راه برای تنظیم فایل‌های آرایش برای موقعیت‌های مختلف

شرح

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

بنا کتابخانه ها
Do شما واقعا نیاز a کتابخانه؟

من تعدادی برنامه بزرگ را دیده ام که از تعداد زیادی ماژول تشکیل شده است
که در فهرست خود زندگی می کند. معمولاً هر دایرکتوری در کتابخانه خودش قرار می گیرد،
و سپس برنامه نهایی با تمام کتابخانه ها پیوند می یابد.

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

1. هنگامی که شما یک دسته از برنامه های فرعی دارید که باید با چندین برنامه مختلف مرتبط شوند
برنامه‌ها، و هیچ برنامه‌ای در واقع از 100% زیر روال‌ها استفاده نمی‌کند - هر برنامه از a استفاده می‌کند
زیر مجموعه های مختلف در این مورد، احتمالاً ایده خوبی است که از یک کتابخانه استاتیک (الف
.a فایل یا یک فایل آرشیو).

2. هنگامی که شما یک ماژول دارید که باید به چندین برنامه مختلف پیوند داده شود، و شما
می خواهید آن را به صورت پویا بارگذاری کنید تا هر برنامه نیازی به کپی جداگانه نداشته باشد
کتابخانه. کتابخانه های پویا می توانند فضای فایل اجرایی را ذخیره کرده و گاهی اوقات آن را افزایش دهند
عملکرد سیستم زیرا تنها یک نسخه از کتابخانه برای همه آنها بارگذاری شده است
برنامه های مختلفی که از آن استفاده می کنند.

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

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

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

اگر ماژول شما هرگز در هیچ برنامه دیگری استفاده نخواهد شد، پس دلیل کمی برای استفاده وجود دارد
یک کتابخانه: شما تمام معایب استفاده از کتابخانه ها را دارید و هیچ یک از مزایا را ندارید.
تکنیکی که من ترجیح می دهم استفاده از پیوند افزایشی است، در جایی که در دسترس است.

در اینجا نحوه انجام این کار در لینوکس آمده است:

my_module.o : $(filter_out my_module.o، $(wildcard *.o))
ld -r -o $(خروجی) $(ورودی ها)

کاری که این کار انجام می دهد ایجاد دیگری است .o فایل فراخوانی شد my_module.o، که شامل خواهد شد
همه ی .o فایل های موجود در این زیر شاخه پیوند دهنده به تعداد زیادی از موارد حل خواهد شد
تا جایی که می تواند ارجاع می دهد، و بقیه ارجاعات را می گذارد تا در الف حل و فصل شوند
مرحله بعدی پیوند در سطح بالا، زمانی که در نهایت برنامه خود را می سازید،
به جای پیوند با libmy_module.a or libmy_module.so، شما به سادگی با
my_module.o. وقتی لینک می کنید .o فایل‌ها، شما مشکلی با وابستگی به سفارش ندارید
خط فرمان لینکر

اجازه دادن makepp شکل خارج که کتابخانه ماژول ها هستند ضروری

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

اگر کتابخانه شما قراردادی را که همه توابع یا کلاس‌ها در آن اعلام شده‌اند، به شدت رعایت می‌کند
یک فایل xyz.h به طور کامل در یک فایل منبع که کامپایل می شود پیاده سازی می شوند xyz.o (یعنی تو
پیاده سازی را به دو قسمت تقسیم نکنید xyz1.o و xyz2.o، سپس می توانید از
تابع "$(infer_objects)" برای اینکه به makepp بگوید فقط ماژول های مربوطه را از آن خارج کند
کتابخانه این می تواند به طرز شگفت انگیزی برای کتابخانه هایی با حتی ده ها فایل شامل به خوبی کار کند.
اساساً، "$(infer_objects)" لیستی از .h فایل هایی که گنجانده شده اند و به نظر می رسد
برای متناظر .o فایل ها. اگر به سرعت در حال توسعه یک کتابخانه و یک برنامه هستید
با هم، این می تواند در زمان کامپایل صرفه جویی کند، زیرا شما هرگز زحمت کامپایل کردن ماژول های آن را نمی دهید
کتابخانه ای که برنامه از آن استفاده نمی کند.

در اینجا یک مثال از روش استفاده من آورده شده است:

my_program: $(infer_objects *.o، $(LIB1)/*.o $(LIB2)/*.o)
$(CXX) $(ورودی ها) -o $(خروجی) $(SYSTEM_LIBRARIES)

تابع "$(infer_objects )" اولین آرگومان خود را (پس از انجام حروف عام) برمی گرداند.
گسترش بر روی آن)، و همچنین فهرست فایل‌ها را در آرگومان دوم خود، برای بررسی می‌کند
فایل هایی که نام آنها با نام هر کدام یکی است .h فایل هایی که توسط هر فایلی در اولین فایل آن گنجانده شده است
بحث و جدل. اگر چنین فایل هایی یافت شد، به لیست اضافه می شوند.

بنا a ایستا کتابخانه

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

LIBRARY_FILES = abcde

libmine.a: $(LIBRARY_FILES).o
&rm -f $(خروجی)
$(AR) cr $(خروجی) $(ورودی ها)
ranlib $(output) # بسته به سیستم عامل شما ممکن است ضروری نباشد.

&rm دستور "rm" داخلی makepp است. اگر به نوشتن فایل های آرایشی عادت دارید، ممکن است این کار را انجام دهید
کمی از این دستور تعجب کرد. ممکن است به چیزی شبیه این عادت کرده باشید:

libmine.a: $(LIBRARY_FILES).o
$(AR) ru $@ $؟ # توصیه نمیشود!!!!!!!
ranlib $(خروجی)

کجا دلار (همچنین به عنوان "$(changed_inputs)" شناخته می شود) یک متغیر خودکار است که به معنای هر فایلی است.
که از آخرین باری که کتابخانه ساخته شد تغییر کرده اند و $@ تقریباً یکسان است
به عنوان "$(خروجی)".

این روش به چند دلیل توصیه نمی شود:

· فرض کنید یک فایل منبع را از دایرکتوری فعلی حذف کرده اید. هنوز در
کتابخانه، زیرا شما کتابخانه را از ابتدا بازسازی نکردید. در نتیجه هر چیزی
که پیوندهای این کتابخانه کهنه خواهند شد .o فایل، و این می تواند شما را خراب کند
می سازد. (زمانی که می خواستم کد مرده را حذف کنم، یک بار با این موضوع کاملا گیج شدم
از یک پروژه: من به حذف فایل‌ها ادامه دادم و هنوز هم پیوند داده می‌شود، بنابراین فکر کردم این کد است
مرده. با این حال، زمانی که شخص دیگری پروژه را از ابتدا بازسازی کرد، هیچکدام را پیوند نداد
بیشتر! مشکل این بود که قدیمی .o فایل ها هنوز در آرشیو بودند.)

همچنین، بسته به گزینه های شما برای "ar" و اجرای "ar" شما (به عنوان مثال، اگر شما
از گزینه "q" به جای "r" استفاده کنید)، می توانید چندین نسخه از آن را داشته باشید
همان .o درون .a فایل. اگر نسخه های مختلف جهانی های متفاوتی را تعریف می کنند،
لینکر ممکن است سعی کند هر دوی آنها را وارد کند. این احتمالاً چیز بدی است.

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

· یکی از راه هایی که makepp برای تضمین ساخت های صحیح تلاش می کند این است که این کار را انجام می دهد
اگر خط فرمان برای ساخت یک هدف معین تغییر کرده باشد، به طور خودکار بازسازی شود. ولی
با استفاده از دلار؟ متغیر می تواند مشکلاتی ایجاد کند، زیرا هر بار که کتابخانه به روز می شود،
دستور ساخت متفاوت است. (شما می توانید این را با استفاده از آن سرکوب کنید
":build_check ignore_action"; برای جزئیات بیشتر به makepp_build_check مراجعه کنید.)

· به روز رسانی آرشیو به جای بازسازی آن، makepp را غیرممکن می کند
فایل را به درستی در یک build cache قرار دهید (برای جزئیات به makepp_build_cache مراجعه کنید).

گاهی اوقات ممکن است متوجه شوید که فهرست کردن همه فایل ها کمی دردناک است، به خصوص اگر a
پروژه به سرعت در حال توسعه است و لیست فایل ها دائما در حال تغییر است. آی تی
ممکن است ساخت کتابخانه با استفاده از حروف عام ساده تر باشد، مانند این:

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

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

تابع "only_targets" برای حذف استفاده می شود .o فایل هایی که متناظر ندارند
فایل های منبع دیگر فرض کنید فایلی به نام داشتید xyz.c که قبلاً در خود قرار می دادید
کتابخانه این به این معنی است که وجود دارد xyz.o پرونده در اطراف حالا شما حذف کنید xyz.c
چون منسوخ شده است، اما فراموش می کنید که حذف کنید xyz.o. بدون "only_targets"
عملکرد، xyz.o همچنان در لیست گنجانده می شود .o فایل های موجود در کتابخانه

بنا a پویا کتابخانه

فرآیند ساخت کتابخانه های پویا کاملاً وابسته به سیستم است. من به شدت
توصیه می کنیم از libtool برای ساخت یک کتابخانه پویا استفاده کنید (نگاه کنید به
<http://www.gnu.org/software/libtool/>)، بنابراین لازم نیست بفهمید که چگونه این کار را انجام دهید
پلتفرم شما، و به این ترتیب که فایل میک شما حتی زمانی که به a تغییر می‌دهید به کار خود ادامه می‌دهد
سیستم عامل های مختلف برای جزئیات بیشتر به مستندات libtool مراجعه کنید. در اینجا یک نمونه Makefile است:

LIBTOOL := libtool

libflick.la : $(only_targets *.lo)
$(LIBTOOL) --mode=پیوند $(CC) $(ورودی ها) -o $(خروجی)

%.lo : %.ج
$(LIBTOOL) --mode=کامپایل $(CC) $(CFLAGS) $(شامل) -c $(ورودی) -o $(خروجی)

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

استفاده کنید a مختلف شامل پرونده in تمام la محیط

در ابتدای هر فایل میک می‌توانید خطی مانند زیر را وارد کنید:

system_defs.mk را شامل شود

پرونده system_defs.mk معمولاً برای هر یک در مکان متفاوتی قرار می گیرد
محیط. اگر می خواهید دایرکتوری های ساخت شما در همه ماشین ها یکسان باشد، آن را قرار دهید
system_defs.mk در دایرکتوری بالای دایرکتوری های ساخت یا در غیر این صورت یک مسیر شامل ارائه دهید
به makepp با استفاده از گزینه خط فرمان "-I".

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

استفاده کنید if اظهارات

این زشت ترین راه برای انجام آن است، اما معمولاً جواب می دهد.

ifsys i386
CC := gcc
دیگری ifsys sun4u
سی سی := سی سی
دیگری ifsys hpux11
CC = c89
انتهایی

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

پیدا_برنامه، first_available Findfile

این توابع می توانند دایرکتوری های مختلف را در سیستم شما جستجو کنند تا آن را پیدا کنند
فایل های مناسب البته این به اندازه یک اسکریپت پیکربندی قدرتمند نیست، اما من آن را پیدا کردم
مفید به عنوان مثال، من کارهای زیر را انجام می دهم:

CXX ;= $(find_program g++ c++ pg++ cxx CC aCC)
# اولین کامپایلر C++ را انتخاب کنید که در PATH موجود است.
# (اتفاقاً اگر اصلاً CXX را تعریف نکنید، این است
# روشی است که تعریف شده است.)
TCL_INCLUDE ;= -I$(dir_noslash $(findfile tcl.h, \
/usr/local/stow/tcl-8.4.5-nothread/include \
/usr/include/tcl8.4 /usr/include/tcl \
/net/na1/tcl8.4a3/include /net/na1/tcl8.4a3/include))
# $(findfile ) به دنبال tcl.h در هر یک از موارد نشان داده شده است
# دایرکتوری و مسیر کامل را برمی گرداند. این پس از آن است
# با حذف کردن به یک گزینه کامپایل تبدیل می شود
# نام فایل (با خروج از فهرست) و پیشوند -I.
%o : %cpp
$(CXX) $(CXXFLAGS) $(TCL_INCLUDE) $(ورودی) -o $(خروجی)

TCL_LIB ;= $((first_available
/usr/local/stow/tcl-8.4.5-nothread/lib/libtcl8.4.so
/usr/lib/libtcl8.4.so /usr/lib/libtcl.so
‎/net/na1/tcl8.4a3/lib/libtcl8.4.a
‎/net/na1/tcl8.4a3/lib/libtcl8.4.sl))
# مکان کتابخانه Tcl را پیدا کنید. این به صراحت است
# در دستور پیوند ذکر شده است:
my_program : *.o
$(CXX) $(CXXFLAGS) $(ورودی ها) -o $(خروجی) $(TCL_LIB)

گرفتن مزیت of پرل پیکربندی اطلاعات

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

اسکریپت پیکربندی خودکار پرل تمام اطلاعات پیکربندی خود را از طریق در دسترس قرار می دهد
هش %Config. هیچ نحوی برای دسترسی مستقیم به هش Perl در makepp وجود ندارد، اما شما می توانید
وارد پرل شوید و متغیرهای اسکالر را تنظیم کنید که مستقیماً از makepp در دسترس هستند:

perl_begin
# مقادیر را از هش پیکربندی واکشی کنید.
از Config استفاده کنید.
$CC = $Config{'cc'}; # کامپایلر C که پرل استفاده می کند.
$byteorder_flags = "-DBYTEORDER=$Config{'byteorder'}";
$longdouble_defined = $Config{'d_longdbl'} معادله 'define';
$CFLAGS_for_shared_libs = $Config{'cccdlflags'};
$LDFLAGS_for_shared_libs = $Config{'ccdlflags'};
perl_end

همچنین، هنگامی که "use Config" را انجام دادید، می توانید از عبارت "$(perl )" مانند
این:

SHARED_LIB_EXTENSION := $(perl $Config{'dlext'})

"perldoc Config" را تایپ کنید تا ببینید چه اطلاعاتی از طریق هش %Config در دسترس است.

پیکربندی پرل مکان خوبی برای دریافت چیزهایی مانند اطلاعات در مورد انواع عدد صحیح، بایت است
سفارش، و چیزهای دیگری که معمولاً به یک اسکریپت پیکربندی جداگانه برای مکان یابی نیاز دارند. بعضی از
اطلاعات مربوط به وجود چیزها در سیستم فایل ممکن است نباشد
معتبر. برای مثال، $Config{'cc'} به کامپایلر C اشاره دارد که perl با آن ساخته شده است.
که ممکن است همان کامپایلر C نباشد که می خواهید استفاده کنید. در واقع، ممکن است حتی وجود نداشته باشد
روی سیستم شما، زیرا احتمالاً Perl را از طریق یک بسته باینری نصب کرده اید.

نکات برای با استفاده از کارت های وحشی
تطابق تمام فایل ها جز a معین زیرمجموعه

وایلد کارت های Makepp در حال حاضر هیچ راهی برای تطبیق همه فایل ها ندارند جز یک خاص
تنظیم کنید، اما می توانید آن را با ترکیبی از توابع انجام دهید.

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

libproduction.a: $(test_out*، $(wildcard *.o))

توابع "$(filter )" و "$(filter_out )" مجموعه بسیار قدرتمندی از فیلترها هستند که باید انجام شوند.
انواع عملیات تقاطع و تفاضل مجموعه. مثلا،

SUBDIRS ;= $(filter_out *test* *$(ARCH)*, $(Shell find . -type d -print))
# همه زیرشاخه هایی را که ندارند برمی گرداند
# "test" یا $(ARCH) در آنها.

$(فیلتر $(patsubst test_dir/test_%.o، %.o، $(wildcard test_dir/*.o))، \
$(عام *.o))
# فهرستی از فایل‌های .o را در حال حاضر برمی‌گرداند
# دایرکتوری که یک دایرکتوری مربوط به آن وجود دارد
# فایل test_*.o در زیر شاخه test_dir.
$(filter_out $(patsubst man/man3/%.3، %.o، $(wildcard man/man3/*.3))، \
$(عام *.o))
# فهرستی از فایل‌های .o را در حال حاضر برمی‌گرداند
# دایرکتوری که صفحه دستی برای آن وجود ندارد
# با همان نام فایل در زیر شاخه man/man3.

با استفاده از la "$(only_targets )" تابع به از بین بردن بیات .o فایل ها

فرض کنید در حال ساختن یک برنامه یا کتابخانه با دستور build مانند این هستید:

برنامه: *.o
$(CC) $(ورودی ها) -o $(خروجی)

فرض کنید اکنون یک فایل منبع را حذف کرده اید. اگر فراموش کردید که مربوطه را حذف کنید .o فایل،
با وجود اینکه دیگر راهی برای ساخت آن وجود ندارد، همچنان به آن متصل خواهد شد. در
در آینده، makepp احتمالاً این وضعیت را به طور خودکار تشخیص داده و آن را از آن حذف خواهد کرد
لیست عام، اما در حال حاضر، باید به آن بگویید که آن را به صورت دستی حذف کند:

برنامه: $(only_targets *.o)
$(CC) $(ورودی ها) -o $(خروجی ها)

Makepp هیچ راهی برای ساختن کهنه نمی داند .o فایل دیگر از آنجایی که فایل منبع آن است
از بین رفته است، بنابراین تابع "$(only_targets )" آن را از لیست وابستگی حذف می کند.

نکات برای چندگانه دایرکتوری
یکی از دلایل اصلی نوشتن makepp، ساده کردن مدیریت چندگانه بود
دایرکتوری ها Makepp قادر است دستورات ساخت را از چندین makefi ترکیب کند، بنابراین می تواند
به درستی با یک قانون در یک makefile که به فایلی که توسط a ساخته شده است برخورد کنید
میکاپ متفاوت

چی به do in محل of بازگشتی ساخت

Makepp از ساخت بازگشتی برای سازگاری به عقب پشتیبانی می کند، اما به شدت توصیه می شود
که تو نه از آن استفاده کنید. اگر نمی دانید چیست، خوب است.

برای جزئیات بیشتر در مورد اینکه چرا نمی خواهید به «سیستم بهتر برای ساخت های سلسله مراتبی» در makepp مراجعه کنید
از ساخت بازگشتی استفاده کنید، یا در وب برای «ساخت بازگشتی در نظر گرفته شده مضر» جستجو کنید.

به جای انجام یک ساخت بازگشتی برای ایجاد هدف "همه" در هر فایل، این کار است
معمولا راحت تر می توان به makepp اجازه داد تا بفهمد کدام اهداف واقعاً باید ساخته شوند.
علاوه بر این، اگر شما تمام خود را قرار دهید .o و فایل های کتابخانه در همان دایرکتوری
makefiles، سپس makepp به طور خودکار تشخیص می دهد که کدام فایل های make-فایل نیز مورد نیاز است
تنها چیزی که مورد نیاز است این است که سطح بالای شما فایل های مورد نیاز را لیست کند
برای مرحله پیوند نهایی نمونه های زیر را ببینید.

یک تهیه پرونده برای هر دایرکتوری: با ضمنی بارگیری

رایج ترین راه برای مدیریت چندین دایرکتوری، قرار دادن یک فایل ساخت در هر دایرکتوری است
که نحوه ساخت همه چیز را در آن دایرکتوری یا از آن توضیح می دهد. اگر قرار دهید .o فایل در
دایرکتوری مشابه فایل های منبع، سپس بارگیری ضمنی (به "بارگیری ضمنی" در
makepp_build_algorithm) به طور خودکار همه فایل های makepp را پیدا می کند. اگر خود را قرار دهید .o
فایل‌ها در دایرکتوری دیگری (مثلاً در یک زیر شاخه وابسته به معماری)، سپس شما
احتمالاً باید تمام فایل‌های مربوطه را با استفاده از عبارت «load_makefile» بارگیری کند.

در اینجا یک نمونه از makefile سطح بالا برای سلسله مراتب دایرکتوری است که از بارگذاری ضمنی استفاده می کند
برای ساختن برنامه‌ای که شامل بسیاری از کتابخانه‌های مشترک است (اما به «آیا واقعاً نیاز دارید؟» را ببینید
کتابخانه؟" در makepp_cookbook، به دلیل ساختن یک برنامه از مجموعه ای از کتابخانه های مشترک
لزوما ایده خوبی نیست):

# فایل ساخت سطح بالا:
برنامه: main.o **/*.la # پیوند در کتابخانه های مشترک از همه زیر شاخه ها.
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) $(ورودی ها) -o $(خروجی) $(LIBS)

این تقریباً تمام چیزی است که در میکفایل سطح بالا نیاز دارید. در هر زیر شاخه، شما
احتمالاً چنین کاری انجام می دهد:

# Makefile در هر زیر شاخه:
شامل standard_defs.mk # جستجوها ., .., ../ ..و غیره تا آن زمان
# فایل شامل نشان داده شده را پیدا می کند.
# برخی از تعاریف متغیر را در اینجا نادیده بگیرید
SPECIAL_FLAGS := -do_something_different

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

در نهایت، موارد زیر را در قسمت قرار دهید standard_defs.mk فایل (که احتمالا باید
در دایرکتوری سطح بالا قرار گیرد):

# تنظیمات متغیر رایج و قوانین ساخت برای همه دایرکتوری ها.
CFLAGS := -g -O2
INCLUDE_DIR := $(find_upwards شامل)
# جستجو ., .., ../ ..و غیره برای یک فایل یا
# دایرکتوری به نام شامل است، بنابراین اگر قرار دهید
# همه فایل‌های شامل شما در آنجا، این کار را انجام می‌دهد
# پیدا کردن آنها.
شامل := -I$(INCLUDE_DIR)

%.lo : %.ج
$(LIBTOOL) --mode=کامپایل $(CC) $(CFLAGS) $(شامل) -c $(ورودی) -o $(خروجی)

lib$(relative_to ., ..).la: $(only_targets *.lo)
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) -o $(خروجی) $(ورودی ها)
# $(relative_to ., ..) نام جریان را برمی گرداند
# زیر شاخه نسبت به سطح بالا
# زیر شاخه بنابراین اگر این فایل makefile xyz/Makefile باشد،
# این قانون xyz/libxyz.la را می سازد.

# انتشار فایل های شامل عمومی در دایرکتوری شامل سطح بالا:
$(INCLUDE_DIR)/public_%.h : public_%.h
:build_check symlnk
&ln -fr $(ورودی) $(خروجی)

یک تهیه پرونده برای هر دایرکتوری: صریح بارگیری

اگر می خواهید همه چیز خود را بگذارید .o سپس فایل ها را در یک زیر شاخه وابسته به معماری قرار دهید
مثال بالا باید به چیزی شبیه به این اصلاح شود:

# فایل ساخت سطح بالا:
MAKEFILES := $(wildcard **/Makeppfile) # فهرست همه زیرشاخه های به
# فایل های ایجاد شده را از.

load_makefile $(MAKEFILES) # همه آنها را بارگیری کنید.

شامل standard_defs.mk # دستور کامپایل را برای main.o دریافت کنید.

برنامه: $(ARCH)/main.o */**/$(ARCH)/*.la
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) $(ورودی ها) -o $(خروجی) $(LIBS)
# */**/$(ARCH) زیر شاخه را مستثنی می کند
# $(ARCH)، جایی که نمی‌خواهیم بسازیم
# یک کتابخانه مشترک.

هر میک‌فایل دقیقاً مانند قبل خواهد بود:

# Makefile در هر زیر شاخه:
استاندارد_defs.mk را شامل شود
# ... متغیر در اینجا لغو می شود

و در نهایت، standard_defs.mk حاوی چیزی شبیه به موارد زیر است:

# تنظیمات متغیر رایج و قوانین ساخت برای همه دایرکتوری ها.
ARCH ;= $(پوسته uname -s)-$(shell uname -m)-$(shell uname -r)
# گاهی اوقات افراد فقط از $(shell uname -m) استفاده می کنند، اما
# این برای FreeBSD و Linux روی یکسان خواهد بود
# x86. -r واقعاً در لینوکس مفید نیست،
# اما برای سایر سیستم عامل ها مهم است: باینری برای
# SunOS 5.8 معمولاً روی SunOS 5.7 اجرا نمی شود.
&mkdir -p $(ARCH) # مطمئن شوید که دایرکتوری خروجی وجود دارد.
CFLAGS := -g -O2
INCLUDE_DIR := $(find_upwards شامل)
# جستجو ., .., ../ ..و غیره برای یک فایل یا
# دایرکتوری به نام شامل است، بنابراین اگر قرار دهید
# همه فایل‌های شامل شما در آنجا، این کار را انجام می‌دهد
# پیدا کردن آنها.
شامل := -I$(INCLUDE_DIR)

$(ARCH)/%.lo : %c
$(LIBTOOL) --mode=کامپایل $(CC) $(CFLAGS) $(شامل) -c $(ورودی) -o $(خروجی)

$(ARCH)/ lib$(relative_to ., ..).la: $(only_targets *.lo)
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) -o $(خروجی) $(ورودی ها)
# $(relative_to ., ..) نام جریان را برمی گرداند
# زیر شاخه نسبت به سطح بالا
# زیر شاخه بنابراین اگر این فایل makefile xyz/Makefile باشد،
# این قانون xyz/$(ARCH)/libxyz.la را می سازد.

# فایل های شامل عمومی را در دایرکتوری شامل سطح بالا کپی کنید:
$(INCLUDE_DIR)/public_%.h : public_%.h
&cp $(ورودی) $(خروجی)

بطور خودکار ساخت la فایل های ایجاد شده

اگر فایل‌های میک شما بسیار شبیه هستند (مانند مثال بالا)، می‌توانید به Makepp بگویید
تا اگر وجود نداشته باشند، آنها را به صورت خودکار بسازند. فقط موارد زیر را به سطح بالای خود اضافه کنید
makefile:

SUBDIRS := $(filter_out unwanted_dir1 unwanted_dir2، $(wildcard */**))
$(foreach)/Makeppfile: : foreach $(SUBDIRS)
&echo "شامل standard_defs.mk" -o $(خروجی)
&echo "_include addition_defs.mk" -o >>$(خروجی)
# اگر فایل اضافی_defs.mk وجود دارد، پس
# شامل خواهد شد، اما اگر وجود نداشته باشد،
# عبارت _include نادیده گرفته خواهد شد.

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

یک تهیه پرونده فقط at la بالا سطح

اگر همه فایل‌های میک‌فایل شما یکسان هستند، ممکن است بپرسید: چرا باید در هر کدام یک فایل ایجاد کنم
مرحله؟ چرا همه اینها را در فایل سطح بالا قرار نمی دهید؟

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

در اینجا یک مثال از انجام این کار آورده شده است:

# فایل ساخت سطح بالا برای سلسله مراتب دایرکتوری. برنامه را می سازد
# از مجموعه ای از کتابخانه های مشترک به عنوان مثال. (به هشدارهای بالا مراجعه کنید
# برای اینکه چرا ممکن است بخواهید از پیوند افزایشی یا موارد دیگر استفاده کنید
# رویکرد به جای کتابخانه های مشترک.)
makepp_percent_subdirs := 1 # اجازه دهید % با چندین فهرست مطابقت داشته باشد.
SUBDIRS := $(filter_out *CVS* other-unwanted_dirs $(wildcard **))
CFLAGS := -g -O2
شامل: = -شامل

%lo: %c
$(LIBTOOL) --mode=کامپایل $(CC) $(INCLUDES) $(CFLAGS) -c $(ورودی) -o $(خروجی)

$ (foreach)/ lib$(notdir $(foreach)).la: $(foreach)/*.lo : foreach $(SUBDIRS)
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) -o $(خروجی) $(ورودی ها)
# قانون برای ایجاد همه کتابخانه ها.

برنامه: main.o ***/*.la
$(LIBTOOL) --mode=پیوند $(CC) $(CFLAGS) -o $(خروجی) $(ورودی ها)

شامل/$(notdir $(foreach)) : $(foreach) : foreach **/public_*.h
&cp $(ورودی) $(خروجی)
# قانون نمونه برای کپی عمومی
# فایل h قابل دسترسی در مکان مناسب.

A تمیز هدف

فایل‌های آرایشی سنتی حاوی یک هدف تمیز هستند که امکان حذف هر چیزی را که وجود داشت را فراهم می‌کند
ساخته شده. سه دلیل وجود دارد که چرا نباید این کار را با makepp انجام دهید:

1. Makepp تمام تلاش خود را می کند تا از ساخت صحیح اطمینان حاصل کند. بنابراین ناامید "من نمی
بدانید چه مشکلی دارد، این که بخواهید از صفر شروع کنید، یک چیز مربوط به گذشته است.

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

3. دستور "makeppclean" وجود دارد که همین کار را انجام می دهد و کارآمدتر است.

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

$ (تمیز ساختگی):
&rm -fm $(wildcard *.o .makepp_log)
# -m و .makepp_log از شر همه آشغال های makepp خلاص می شوند.

به‌جای فهرست کردن صریح فایل‌هایی که می‌خواهید حذف کنید، می‌توانید به makepp نیز بگویید
هر چیزی را که می داند چگونه بسازد را حذف کنید، مانند این:

$ (تمیز ساختگی):
&rm -fm .makepp_log $(only_targets *)

این مزیت را دارد که اگر هر یک از فایل های منبع شما می تواند از فایل های دیگر ساخته شود،
آنها نیز حذف خواهند شد. از سوی دیگر، کهنه .o فایل ها (فایل هایی که قبلا بودند
قابل ساخت اما فایل منبع آن حذف شده است) حذف نخواهد شد.

اگر بیلدی دارید که شامل فایل‌های ساخت در چندین دایرکتوری مختلف است، بهترین شما
سطح makefile ممکن است به هدف "پاک" (یا هر هدف ساختگی دیگر) به شکل دیگری ارجاع دهد
makefile:

# فایل ساخت سطح بالا
SUBDIRS := sub1 sub2

# قوانین را در اینجا بسازید

# پاکسازی پس از ساخت:
$(تمیز ساختگی): $(SUBDIRS)/clean
&rm -fm .makepp_log $(only_targets *)

از طرف دیگر، می‌توانید هدف «پاک» خود را فقط در فایل اولیه سطح بالا قرار دهید و آن را داشته باشید.
همه دایرکتوری ها را مانند زیر پردازش کنید:

$ (تمیز ساختگی):
&rm -fm $(only_targets ***/*)

با استفاده از Qt قدرت پیش پردازنده
این مثال یک فایل ساخت برای ابزاری را نشان می‌دهد که از کتابخانه Qt GUI نوکیا استفاده می‌کند (نگاه کنید به
<http://qt.nokia.com>). تنها چیزی که در این مورد کمی غیرعادی است این است که شما
باید یک پیش پردازنده به نام "moc" را روی اکثر فایل های ".h" که حاوی تعاریف ویجت هستند اجرا کند،
اما شما نمی خواهید "moc" را روی هیچ فایل ".h" که از ماکرو "Q_OBJECT" استفاده نمی کند، اجرا کنید.

بطور خودکار تعیین که فایل ها نیاز قدرت فایل ها

البته می‌توانید تمام فایل‌های «.h» را که باید «moc» روی آن‌ها اجرا شود، فهرست کنید.
با این حال، اگر به سرعت در حال توسعه ویجت‌های جدید هستید، ممکن است برایتان آزاردهنده باشد
به روز رسانی لیست موجود در makefile ادامه دهید. می‌توانید نیاز به فهرست کردن موک را برطرف کنید
ماژول ها به صراحت با چیزی شبیه به این:

MOC := $(QTDIR)/bin/moc
ماژول ها: = هر ماژول که در برنامه خود دارید
MOC_MODULES := $(patsubst %.h، moc_%, $(&grep -l /Q_OBJECT/ *.h))
# همه فایل‌های h را برای ماکرو Q_OBJECT اسکن می‌کند.

my_program: $(MODULES).o $(MOC_MODULES).o
$(CXX) $(ورودی ها) -o $(خروجی)

moc_%.cxx: %.h # فایل‌های moc را از فایل‌های .h می‌سازد.
$(MOC) $(ورودی) -o $(خروجی)

%.o: %.cxx
$(CXX) $(CXXFLAGS) -c $(ورودی) -o $(خروجی)

این رویکرد هر یک از شما را اسکن می کند .h هر بار که makepp اجرا می شود، به دنبال فایل می گردد
ماکرو "Q_OBJECT". این گران به نظر می رسد، اما احتمالاً اصلاً طول نخواهد کشید. ( .h
به هر حال در فرآیند کامپایل، فایل‌ها باید از دیسک بارگیری شوند، بنابراین این کار انجام می‌شود
کش شود.)

#include la .moc پرونده

روش دیگر این است که خروجی پیش پردازنده "moc" را در ویجت خود "# شامل" کنید
فایل پیاده سازی این بدان معناست که شما باید یادتان باشد که "#include" را بنویسید، اما اینطور است
مزیت این است که ماژول های کمتری برای کامپایل وجود دارد و بنابراین کامپایل سریعتر انجام می شود.
(برای اکثر کامپایل‌های ++C، بیشتر زمان صرف خواندن فایل‌های هدر می‌شود
خروجی از پیش پردازنده باید تقریباً به اندازه ویجت شما شامل فایل باشد
به هر حال.) به عنوان مثال:

// my_widget.h
class MyWidget : public QWidget {
Q_OBJECT
//...
}

// my_widget.cpp

#include "my_widget.h"
#include "my_widget.moc" // my_widget.moc خروجی از
// پیش پردازنده moc.
// سایر موارد اجرایی در اینجا.
MyWidget::MyWidget (QWidget * والد، کاراکتر اصلی * نام):
QWidget (والد، نام)
{
//...
}

اکنون باید یک قانون در میکفایل خود داشته باشید تا همه فایل های ".moc" را بسازید، مانند این:

MOC := $(QTDIR)/bin/moc
# قانون ساخت فایل‌های .moc:
%.moc: .h
$(MOC) $(ورودی) -o $(خروجی)

Makepp آنقدر باهوش است که بفهمد اگر این کار را نکند باید "my_widget.moc" بسازد.
در حال حاضر وجود دارد، یا اگر قدیمی باشد.

این روش دوم همان روشی است که من معمولا از آن استفاده می‌کنم زیرا سرعت کامپایل را افزایش می‌دهد.

تعویض برای منسوخ ساخت اصطلاحات
MAKECMDGOALS

گاهی اوقات افراد قوانینی در پرونده خود دارند که بستگی به هدفی دارد که می‌سازند،
با استفاده از متغیر ویژه "MAKECMDGOALS". به عنوان مثال، گاهی اوقات یک چیزهایی مانند
این:

ifneq ($(تولید فیلتر، $(MAKECMDGOALS))،)
CFLAGS := -O2
دیگر
CFLAGS := -g
انتهایی

این به خوبی با makepp کار خواهد کرد. با این حال، توصیه می کنم از "MAKECMDGOALS" برای چنین مواردی استفاده نکنید
موارد (و همینطور راهنمای ساخت گنو). بهتر است بهینه سازی شده خود را قرار دهید
اشکال زدایی کامپایل شده است .o فایل ها در دایرکتوری های جداگانه، یا دادن پیشوندهای مختلف یا
پسوندها یا استفاده از مخازن برای جدا نگه داشتن آنها.

احتمالاً تنها زمانی که ممکن است واقعاً بخواهید به "MAKECMDGOALS" ارجاع دهید، این است
زمان زیادی طول می کشد تا فایل های ایجاد شده خود را بارگذاری کنید، و شما برای هدف "تمیز" خود به آن نیاز ندارید
(اما شما به یک هدف تمیز نیاز ندارید). مثلا،

ifneq ($(MAKECMDGOALS)، پاک)
load_makefile $(عام **/Makeppfile)
دیگر
no_implicit_load . # جلوگیری از بارگذاری خودکار هر گونه فایل دیگر.
انتهایی

$ (تمیز ساختگی):
&rm -f $(عام ***/*.o)

بازگشتی ساخت به ساختن in مختلف دایرکتوری

به "نکاتی برای چندین فهرست" در makepp_cookbook مراجعه کنید.

بازگشتی ساخت به تغییر دادن ارزش of a متغیر

برخی از فایل‌های ساخت مجدداً خود را با مقدار متفاوتی از یک متغیر فراخوانی می‌کنند، مثلاً اشکال‌زدایی
هدف در قطعه makefile زیر

.PHONY: همه اشکال زدایی

بهینه شده:
برنامه $(MAKE) CFLAGS=-O2

اشکال زدایی:
برنامه $(MAKE) CFLAGS=-g

برنامه: ao bo
$(CC) $(CFLAGS) $^ -o $@

%o : %c
$(CC) $(CFLAGS) -c $< -o $@

اگر کاربر "make debug" را تایپ کند، برنامه را در حالت پیش فرض با فعال کردن اشکال زدایی می سازد
به جای بهینه سازی

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

CFLAGS := -O2
DEBUG_FLAGS := -g
ماژول ها: = ab

برنامه: $(MODULES).o
$(CC) $(CFLAGS) $(ورودی ها) -o $(خروجی)

اشکال زدایی/برنامه: debug/$(MODULES).o
$(CC) $(DEBUG_FLAGS) $(ورودی ها) -o $(خروجی)

%o : %c
$(CC) $(CFLAGS) -c $(ورودی) -o $(خروجی)

اشکال زدایی/%.o : %.c
$(CC) $(DEBUG_FLAGS) -c $(ورودی) -o $(خروجی)

$ (اشکال‌زدایی ساختگی): اشکال‌زدایی/برنامه

مزیت انجام این کار این است که (الف) نیازی به بازسازی همه چیز ندارید
تغییر از اشکال زدایی به بهینه سازی و بازگشت دوباره. (ب)

موارد فوق را می توان با استفاده از مخازن تا حدودی مختصرتر نوشت. به شرح زیر
makefile دقیقاً معادل است:

اشکال زدایی مخزن=. # زیرشاخه اشکال زدایی را شبیه کپی می کند
# زیر شاخه فعلی.
اشکال زدایی load_makefile CFLAGS=-g
# CFLAGS را هنگام فراخوانی در زیر شاخه اشکال زدایی لغو کنید
CFLAGS := -O2 # مقدار CFLAGS هنگام فراخوانی در این زیر شاخه

برنامه: ao bo
$(CC) $(CFLAGS) $^ -o $@

%o : %c
$(CC) $(CFLAGS) -c $< -o $@

$ (اشکال‌زدایی ساختگی): اشکال‌زدایی/برنامه
# اگر کاربر "makepp debug" را تایپ کند، می سازد
# اشکال زدایی/برنامه به جای برنامه.

متفرقه نکات
چگونه do I ساختن یک بخش متفاوت است تنها یک بار؟

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

makepp DEBUG=3 buggy.o # آن را با گزینه دیگری بسازید.
makepp --dont-build=buggy.o buggy # با وجود گزینه ساخت "اشتباه" از آن استفاده کنید.

چگونه do I ساخت مطمئن my تولید دایرکتوری وجود دارد؟

می توانید یک قانون برای ساخت دایرکتوری خروجی مشخص کنید، سپس مطمئن شوید که هر فایلی که
می رود در دایرکتوری خروجی بستگی به آن دارد. اما معمولاً انجام چنین کاری آسانتر است
این:

# روش کلاسیک
ساختگی := $(تست پوسته -d $(OUTPUT_DIRECTORY) || mkdir -p $(OUTPUT_DIRECTORY))
# این معمولا ساده تر از وابستگی همه فایل ها به آن است
# $(OUTPUT_DIRECTORY) و داشتن یک قانون برای ایجاد آن.
# توجه داشته باشید که باید به جای = از := برای اجبار استفاده کنید
# بلافاصله اجرا کنید.
# یک رویکرد جایگزین: با استفاده از کد پرل، OUTPUT_DIRECTORY محلی var
perl_begin
-d $OUTPUT_DIRECTORY یا mkdir $OUTPUT_DIRECTORY.
perl_end
# روش مدرن، هیچ کاری برای دایرکتوری های موجود انجام نمی دهد
&mkdir -p $(OUTPUT_DIRECTORY)

یکی از این عبارات باید نزدیک بالای فایل ایجاد شده شما باشد، بنابراین آنها اجرا می شوند
قبل از هر چیزی که احتمالاً به دایرکتوری نیاز دارد.

چگونه do I مجبور a فرمان به اجرا کردن on هر ساختن؟

ساده ترین راه این است که به هیچ وجه از مکانیسم قانون استفاده نکنید، بلکه به سادگی آن را اجرا کنید، مانند
این:

ساختگی := $(تاریخ پوسته > last_build_timestamp)

یا آن را در یک بلوک پرل قرار دهید، مانند این:

perl_begin
system("فرمان اجرا");
perl_end

این رویکرد دارای این عیب است که حتی اگر یک هدف نامرتبط اجرا شود، اجرا می شود
در حال اجرا شدن

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

چگونه do I کوتاه کردن la نمایش داده ساختن دستورات؟

اغلب گزینه های زیادی برای دستورات کامپایل وجود دارد که آنچه در آن نمایش داده می شود
صفحه نمایش قابل خواندن نیست شما می توانید آنچه را که نمایش داده می شود با سرکوب کردن نمایشگر تغییر دهید
کل دستور، و سپس به صراحت قسمت جالب دستور را چاپ کنید. این است
با استفاده از "$(filter_out )" به راحتی می توان تنها قسمت مربوطه از دستور را چاپ کرد
این:

ALL_CFLAGS = $(CFLAGS) $(INCLUDES) $(ADDL_CXX_FLAGS) $(DEBUG_FLAGS)

%o : %c
@&echo $(notdir $(CC)) ... \
$(filter_out -I* $(ADDL_CXX_FLAGS)، $(ALL_CFLAGS)) \
-c $(ورودی)
@$(CC) $(ALL_CFLAGS) -c $(ورودی) -o $(خروجی)

("@" در جلوی دستور، چاپ دستور را متوقف می کند.)

این به شما امکان می دهد بیشتر گزینه های جالب را ببینید اما همه آنها را نمایش نمی دهد
شامل دایرکتوری ها (که اغلب تعداد زیادی از آنها وجود دارد!). اگر قسمت مورد علاقه شماست
in در دستور شما به هم پیوسته است، همچنین می توانید از تابع "print" استفاده کنید (که a را اضافه می کند
خط جدید، بنابراین شما چندین مورد از آنها را نمی خواهید):

هدف:
@... $(چاپ قسمت جالب) ...

چگونه do I تبدیل a پرونده به وابستگی ها؟

برای برخی از فرمت های فایل مبهم، پیاده سازی یک اسکنر ارزشمند نیست. در یک پروژه
مثلا ما فایل های xml داریم foobar.xml که حاوی وابستگی برای foobar.out:


آ
ب
ج


ما تصمیم گرفتیم به این طرح ساده پایبند باشیم، بنابراین نیازی به تجزیه xml نداریم. با
ساخته شده در &sed، در اینجا کاری است که ما با سه جایگزین ساده برای سه نوع انجام می دهیم
خطوط:

%d: %xml
&sed's! !$(stem).out: \\! || s! (.+) !$1 \\! || s! !# خالی!' \
$(ورودی) -o $(خروجی)

شامل foobar.d

با تلاش برای گنجاندن این، ابتدا "foobar.d" تولید می شود:

foobar.out: \
آ \
b \
ج \
# خالی

خط خالی (فقط یک نظر یا واقعاً خالی) از نگرانی در مورد دنباله اجتناب می کند
بک اسلش یک جایگزین برای تولید یک لیست چند خطی این است:

%d: %xml
&sed's! !$(stem).out: \$$((! || s! !))! || s!<.+?>!!g' \
$(ورودی) -o $(خروجی)

شامل foobar.d

این یک معادل تولید می کند:

foobar.out: $((
a
b
c
))

اگر بازنویسی پیچیده تری برای انجام دارید، یک تابع را در makefile یا در a تعریف کنید
ماژولی که شما گنجانده اید. به عنوان مثال، تعریف نکردن $_ از خطوط ورودی عبور می کند:

زیر فیلتر مای {
اگر /
my $stem = f_stem;
s! !$stem.out: \$((! || s! !))! || s!<.+؟>!!g;
}

%d: %xml
&sed's! !$(stem).out: \$$((! || s! !))! || s!<.+?>!!g' \
$(ورودی) -o $(خروجی)

شامل foobar.d

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