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

برنامه:

نام

makepp_scanning - چگونه پیداهای makepp شامل فایل‌ها و سایر وابستگی‌های پنهان می‌شود

شرح

Makepp می تواند وابستگی ها یا اهداف اضافی را برای دستورات خاصی که می داند تعیین کند
چیزی در مورد. این امر مخصوصاً برای کامپایل C/C++، جایی که هم هست، مهم است
مستعد خطا برای فهرست کردن دستی همه فایل های شامل که یک فایل منبع معین به آنها وابسته است.
makepp با مشاهده دستور کامپایل و خود فایل های منبع قادر به انجام این کار است
زمانی که برخی از فایل‌ها شامل تغییرات فایل می‌شوند، دقیقاً تعیین کنید که کدام فایل‌های شی باید بازسازی شوند.

مثال: با توجه به یک قانون

foo.o: # معمولاً %o: %c، فقط برای مثال
time -p /bin/libtool -bar /usr/bin/cc -c -من در جایی foo.c

makepp می داند که "time" و "libtool" باید نادیده گرفته شوند و "cc" فرمان واقعی است.
در اینجا تجزیه شود. این را می فهمد foo.c فایل ورودی و در نتیجه وابستگی به است
این قانون علاوه بر این، آن فایل را به دنبال عبارات شامل اسکن می کند
فهرست راهنما یک جایی، زیرا گزینه های فرمان را درک می کرد.

در واقع سه مرحله برای آنچه در تاریخ به عنوان اسکن شناخته می شود وجود دارد:

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

دستورات در بک‌کوتیشن تحلیل می‌شوند اما اجرا نمی‌شوند. (اغلب اجرا مهم است،
اما این یک تداخل عمده توسط makepp خواهد بود.) بهتر است از آنها اجتناب کنید.
در عوض، makepp را با تخصیص آن به این روش خاص، حداکثر یک بار دستور اجرا کنید:

XYZFLAGS ;= $(شل pkg-config --cflags xyz)

در حال حاضر تنها یک کلاس lexer وجود دارد که Bourne Shell را درک می کند. برای بهتر شدن
C Shell یا "command.com" را کنترل کنید، ممکن است زیر کلاس‌هایی ایجاد شود. با این حال، نحو بسیار است
به اندازه کافی مشابه که این امر را تضمین نمی کند. در صورت تمایل به همکاری با ما تماس بگیرید.

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

حتی اگر تجزیه کننده تخصصی پیدا نشد، تجزیه کننده عمومی دستور را قابل اجرا می کند
ورودی این قانون می توانید آن را با --no-path-executable-dependencies تغییر دهید
گزینه فرمان.

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

این گران ترین مرحله است. همه نتایج برای جلوگیری از تکرار آن ذخیره می شوند
بی مورد

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

%o: %c
@echo در حال کامپایل $<. obscure_wrapper gcc -c $< $(CFLAGS) -o $@

اولین کلمات اعمال در اینجا "پژواک" و "مبهم_پوشش" است که برای آنها وجود دارد.
بدون تجزیه کننده، بنابراین makepp فایل های شامل را در این مورد اسکن نمی کند. می توانید نادیده بگیرید
دستور پیشوند توسط:

register-parser obscure_wrapper skip-word

بخش‌های زیر تجزیه‌کننده‌ها و اسکنرهای داخلی را مستند می‌کنند. به نام شما می توانید
از "-" به جای "_" استفاده کنید.

اسکنرها (تجزیه کننده ها)

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

C / C ++ تالیف (c-compilation, gcc-compilation)
اسکنر C/C++، هر دو زبان را بی تفاوت مدیریت می کند. در واقع فقط به آن نگاه می کند
دستورات پیش پردازنده، بنابراین می توان از آن برای تعداد زیادی زبان استفاده کرد. تجزیه کننده که
آن را فعال می کند یک نوع خاص برای گزینه های متعدد gcc دارد که در صورت انتخاب انتخاب می شود
نام فرمان شامل رشته "gcc" یا g++ است. اگر کامپایلر برای زبان های دیگر با C
پیش پردازنده از همان گزینه های کامپایلر C استفاده می کند (حداقل "-I") سپس این تجزیه کننده کار می کند
خوب.

به دستور گزینه های "-Idir" نگاه می کند و مسیر شامل یا گزینه های "-Ldir" را مشخص می کند
تعیین مسیر پیوند سپس هر فایل منبع را برای دستورالعمل های "#include" اسکن می کند و
همچنین به خط فرمان نگاه می کند تا ببیند آیا فایل های منبع یا کتابخانه ای ذکر شده است یا خیر
که به عنوان وابستگی فهرست نشده اند. اینها را با بسط آنها تشخیص می دهد.

اگر فایل‌های موجود با "#include "file.h"" نباشند، این اسکنر یک پیام هشدار می‌دهد
یافت شده یا توسط makepp قابل ساخت نیست، در مسیر include، یا در دایرکتوری حاوی the
فایلی که "#includ" یا در است / usr / شامل. در صورت وجود فایل هیچ هشداری داده نمی شود
با "#شامل " یافت نشد. Makepp فرض می کند که در برخی از سیستم ها وجود دارد
دایرکتوری که کامپایلر درباره آن می داند و فایل های موجود در سیستم شامل دایرکتوری ها می شود
تغییر نخواهد کرد

علاوه بر این، فایل ها در / usr / شامل, /usr/local/include, /usr/X11R6/include، و هر دیگری
دایرکتوری که قابل نوشتن نیست اسکن نمی شود تا ببیند شامل چه مواردی می شود. Makepp فرض می کند
که این فایل ها تغییر نخواهند کرد (اگر به صورت روت اجرا می کنید، تست قابلیت نوشتن است
با UID و GID دایرکتوری که makepp را اجرا کردید انجام می شود. این خیلی کامپایل است
یک برنامه به عنوان یک کاربر معمولی و سپس انجام "makepp install" به عنوان روت باعث اضافی نمی شود
دایرکتوری هایی که باید اسکن شوند.)

این یک اسکنر نسبتا ساده است. اگر کارهایی مانند این را انجام دهید گیج می شود:

#ifdef شامل_این است
#شامل "this.h"
# اندیف

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

اگر کامپایلر شما نام خنده‌داری دارد، می‌توانید یکی از آن‌ها را بگویید

register-parser obscure_c_compiler c-compilation
register-parser obscure_gcc_alias gcc-compilation

جاسازی شده SQL C / C ++ تالیف (Esql-Compilation)
این دستورات که با پایگاه داده های مختلف ارائه می شوند، بخش های خاصی را در آن پیش پردازش می کنند
در غیر این صورت منابعی شبیه به C/C++، و هدرها و منابع C/C++ تولید می کنند. این EXEC SQL را پیدا می کند
شامل دستورالعمل های "filename" یا $INCLUDE "filename".

این پیش پردازنده ها شناخته شده اند: Altibase APRE*C/C++ (به پایان رساندن)، CASMaker DBMaker
(dmppcc)، فایربرد / اینتر بیس (gpre, IBM DB2 (db2 از پیش کامپایل، db2 دبستان) & Informix
ESQL/C (esql) , انگرس (esqlc), میمر (esqlاوراکل (مجموعه مقالات، PostgreSQL (ecpg) & حیاط
(yardpc). اگر پیش پردازنده شما شناسایی نشد، می توانید بگویید

register-parser obscure_esqlc_preprocessor esql-compilation

با این حال، این فقط سبک مشترک Informix و دیگران را کنترل می کند: آرگومان های فرمان
که به ".ec" ختم می شود فایل هایی هستند که باید اسکن شوند، "-I" مسیر include و EXEC SQL را مشخص می کند.
شامل دستورات بدون پسوند دریافت ".h" ضمیمه شده است.

سوئیچ (چرخ زدن)
Swig (ساده شده Wrapper and Interface Generator, http://www.swig.org/) برنامه ای است که
یک فایل هدر C/C++ را به توابع wrapper مورد نیاز برای فراخوانی کد شما تبدیل می کند
از انواع زبان های دیگر مانند Perl، Python، Tcl، C#، Ruby، OCaml و
احتمالاً برخی دیگر که من از آنها اطلاعی ندارم.

Makepp خط فرمان swig را می‌فهمد و تجزیه می‌کند و به دنبال گزینه‌های "-I" و "-l" می‌گردد.
همچنین می داند که چگونه فایل های تعریف رابط Swig را اسکن کند (.i فایل ها) به دنبال
%include، %import، و همچنین «#include» اگر «-includeall» در کار باشد.

اگر سوئیچ شما نام خنده‌داری دارد، می‌توانید بگویید

register-parser obscure_swig_alias swig

ورا و وریلوگ (vcs_compilation)
اگر سخت افزار طراحی می کنید، این به کارتان می آید.

قابل صرف نظر لفافه (پرش کلمه، پوسته)
Makepp کلمات دستوری زیر و بسیاری دیگر را تشخیص می دهد و از روی آنها می گذرد
به طور مناسب در جستجوی اسکنر صحیح: "condor_compile"، "distcc"،
"ignore_error"، "libtool"، "noecho" "purify".

یک نوع از این وجود دارد که دستورات تودرتو را در "sh -c 'command1;
فرمان 2'".

اگر از این دست دستورات بیشتر دارید، می توانید بگویید

دستور register-parser skip-word

Libtool

Libtool یک سیستم کامپایل بسیار هوشمندانه است که اشتراک گذاری را بسیار ساده می کند
کتابخانه ها با پنهان کردن تمام جزئیات وابسته به سیستم در یک پوسته اسکریپت. تنها
مشکل این است که فایل های باینری کتابخانه در واقع در یک دایرکتوری ذخیره نمی شوند
به عنوان فایل خروجی--libtool در واقع یک زیر شاخه به نام ".libs" ایجاد می کند که حاوی
فایل های واقعی این معمولاً یک مشکل نیست، اما makepp باید بداند که کجا واقعی است
باینری ها در صورتی هستند که بخواهند آنها را از یک مخزن به آن پیوند دهند. در حال حاضر، کتابخانه های libtool
فایل‌های (.la") از مخازن پیوند داده نشده‌اند. آنها همیشه در صورت نیاز بازسازی می شوند.
همچنین makepp در حال حاضر قادر به استفاده از اطلاعات وابستگی ذخیره شده نیست
داخل خود فایل ".la". این امیدواریم به زودی تغییر کند.

سرکوبگر la اسکن (هیچ)
گاهی اوقات ممکن است نخواهید یک قانون یا یک دستور خاص تجزیه شود. می توانید خاموش کنید
تجزیه و در نتیجه اسکن با

register-parser cc هیچکدام

مرتبط OPTIONS

اسکن سریع و اسکن هوشمند
گزینه‌های قانون «:quickscan» و «:smartscan»، در صورت وجود، بر نحوه فایل‌ها تأثیر می‌گذارند.
اسکن می شوند.

در حالت ":quickscan" (به طور پیش فرض)، همه دستورالعمل های شامل فعال فرض می شوند. این اجازه می دهد
برای اسکن بسیار کارآمد

در حالت ":smartscan" تلاش می شود تا ماکروها و عبارات را تفسیر کنند تا
دستورالعمل های شامل غیر فعال نادیده گرفته می شوند. به عنوان مثال، اجرایی تولید شده توسط
کامپایل کردن برنامه C زیر باید نه بستگی داشتن به foo.h:

# اگر 0
#شامل "foo.h"
# اندیف
int main() { return 0; }

سفارشی اسکنرها

می توانید تجزیه کننده خود را یا در یک گزینه قانون مانند ":parser foo" یا با استفاده از آن مشخص کنید
عبارات "register_parser" یا "register_command_parser".

در هر صورت، همانطور که در زیر "register_parser" توضیح داده شده است، باید به طور مستقیم یا غیرمستقیم وجود داشته باشد
(از طریق یک کلاس) تابعی را مشخص کنید که یک شی تجزیه کننده ایجاد می کند. این شی معمولا
یک شی اسکنر برای فایل ها ایجاد کنید و آن را با یافته هایش از خط فرمان تغذیه کنید
گزینه ها. این دو شی، متدهای تجزیه‌گر «add_*_dependency» را فراخوانی می‌کنند که
اطلاعات را به "Mpp::Lexer::add_*_dependency" تا حدودی پیچیده تر ارسال کنید.
توابع سودمند

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

"undef"
اطلاعات اسکن قابل ذخیره نیست و دفعه بعد که هدف قانون است باید دوباره محاسبه شود
نیاز به ساخت دارد.

"p_none، p_skip_word" یا "p_shell"
اینها در واقع ثابت های عددی هستند که به lexer می گویند که کار اینها را انجام دهد
تجزیه کننده های شبه

هر مرجع، به عنوان مثال "\1"
این معادل برگرداندن یک شی تجزیه کننده از پایه "Mpp::CommandParser" است.
کلاس، که علاوه بر این فقط دستور قابل اجرا را به خود یک وابستگی تبدیل می کند.

در بیشتر موارد، اشیاء از نوع "Mpp::CommandParser" باید حداقل یک شی را نمونه برداری کنند.
از نوع "Mpp::Scanner". کلاس پایه "Mpp::Scanner" از تمایز مراقبت می کند
بین اسکن سریع و اسکن هوشمند. توجه داشته باشید که رفتار "Mpp::Scanner" می تواند مشخص باشد
تحت تأثیر این تمایز قرار می گیرد، اما در صورت وجود باید برای کلاس مشتق شده شفاف باشد
خوش فرم شده کلاس های مشتق شده جدید "Mpp::Scanner" باید در هر دو حالت آزمایش شوند.

اگر کلاس «Mpp::Scanner» خود را بنویسید، باید تصمیم خود را برای اسکن مجدد نیز پایه گذاری کنید
در اطلاعات ساخت "RESCAN". این توسط "makeppreplay" پس از امضای فایل‌ها بدون تنظیم تنظیم می‌شود
اسکن کردن بنابراین علیرغم اینکه امضاها ثابت هستند، هنوز اسکن مجدد لازم است. اگر
"Mpp::Scanner" شما از روش "scan_file1" به ارث برده شده استفاده می کند، احتمالاً خوب هستید.

برای جزئیات بیشتر، به مستندات کلاس مربوطه مراجعه کنید. برای مثال، نگاه کنید
"Mpp::CommandParser::Gcc" و "Mpp::CommandParser::Vcs". به توابع "p_" در داخل نگاه کنید
Mpp/Subs.pm که هنگام بارگذاری در کلاس های مربوطه خود به عنوان "factory" نام مستعار می شوند.

ذخیره سازی اسکنر اطلاعات
اگر تمام عوارض جانبی مهم اسکنر از طریق فراخوانی متدها انجام شود
از کلاس پایه "Mpp::CommandParser"، سپس آن عوارض جانبی را می توان در ساخت ذخیره کرد
فایل اطلاعات، به طوری که می توان آنها را با فراخوانی بعدی از makepp بدون پخش پخش کرد
انجام تمام کارهای پرهزینه اسکن این می تواند مقدار زیادی در زمان صرفه جویی کند، به خصوص در
حالت اسکن هوشمند

اگر اسکنر عوارض جانبی مهم دیگری دارد، باید شیء "قاعده" را فراخوانی کند
روش mark_scaninfo_uncacheable. در غیر این صورت، اطلاعات اسکنر از بیلد بازیابی می شود
اطلاعات ممکن است نادرست باشد، که باعث می شود نتیجه ساخت احتمالاً نادرست باشد. این روش است
زمانی که مقداری از هش % parsers یک شی از نوع خود را بر نمی گرداند، به طور خودکار فراخوانی می شود
"Mpp::CommandParser"، یا زمانی که تجزیه کننده با یک گزینه قانون و "p_*" مشخص شده است.
روتین یک شی از نوع "Mpp::CommandParser" را بر نمی گرداند.

اطلاعات اسکن ذخیره شده با استفاده از معیارهایی مشابه معیارهایی که برای تعیین زمان استفاده می شود، باطل می شود
هدف قدیمی است به طور مشابه، می توان آن را با استفاده از یک مخزن بازیابی کرد
معیارهایی مشابه معیارهایی که برای تعیین اینکه چه زمانی می توان یک هدف را از a پیوند داد
مخزن

با گزینه "--force-rescan" می توانید makepp را مجبور کنید که اطلاعات اسکنر ذخیره شده را نادیده بگیرد.
این زمانی مفید است که یک اسکنر خراب ممکن است باعث شود اطلاعات اسکنر نادرست در حافظه پنهان ذخیره شود.

Ad هک پوینده
اغلب شما فقط یک یا چند فایل خواهید داشت که حاوی اطلاعات وابستگی هستند. شما این کار را نمی کنید
می خواهید این را به صورت اضافی در یک پرونده بنویسید (زیرا افزونگی بعداً اغلب منجر به
ناهماهنگی زمانی که یک به روز رسانی فراموش می شود). اما شما همچنین نمی خواهید الف بنویسید
Mpp::اسکنر؟ به عنوان یک راه‌حل، می‌توانید یک فایل شامل در پرواز ایجاد کنید. مثلا
Qt دارد .qrc فایل هایی که می توانند شبیه به:



abc
xyz
...

اگر به طرح بالا پایبند باشید، می توانید خطوط مربوطه را به یک makepp تبدیل کنید
شامل فایل، که به طور خودکار با گنجاندن ایجاد می شود.

%.qrc.makepp: %.qrc
&grep's! \n!$(stem).cc:! || s! * ! ! &&s! \n!!' $(ورودی) -o $(خروجی)

شامل $(wildcard *.qrc) # .makepp به طور خودکار اضافه می شود

چندین نوع از این در کتاب آشپزی آورده شده است. اشکال این است که شما شروع می کنید
ساختن در حین خواندن makefile. بنابراین گزینه فرمان --loop چندان کاربردی نخواهد بود
در اولین تکرار

با استفاده از خدمات onworks.net از makepp_scanning آنلاین استفاده کنید