OCAMLOPT(1) General Commands Manual OCAMLOPT(1)

ocamlopt - کامپایلر کد بومی OCaml

ocamlopt [گزینه‌ها] نام‌فایل...
ocamlopt.opt [گزینه‌ها] نام‌فایل...

کامپایلر کد بومی با کارایی بالای OCaml، یعنی ocamlopt(1) فایل‌های منبع OCaml را به فایل‌های شیء کد بومی کامپایل می‌کند و این فایل‌های شیء را برای تولید فایل‌های اجرایی مستقل پیوند می‌دهد.

دستور ocamlopt(1) دارای رابط خط فرمانی بسیار نزدیک به رابط ocamlc(1) است. این دستور همان انواع آرگومان‌ها را می‌پذیرد و پس از پردازش تمام گزینه‌ها، آن‌ها را به‌صورت متوالی پردازش می‌کند:

•
آرگومان‌هایی که به .mli ختم می‌شوند، به عنوان فایل‌های منبع برای رابط‌های واحد کامپایل در نظر گرفته می‌شوند. رابط‌ها نام‌های صادرشده توسط واحدهای کامپایل را مشخص می‌کنند: آن‌ها نام مقادیر را همراه با نوع‌هایشان اعلان می‌کنند، نوع‌های داده عمومی را تعریف می‌کنند، نوع‌های داده انتزاعی را اعلان می‌کنند و غیره. از فایل x.mli، کامپایلر ocamlopt(1) یک رابط کامپایل‌شده در فایل x.cmi تولید می‌کند. رابط تولیدشده با رابطی که توسط کامپایلر بایت‌کد ocamlc(1) تولید می‌شود، یکسان است.
•
آرگومان‌هایی که به .ml ختم می‌شوند، به عنوان فایل‌های منبع برای پیاده‌سازی‌های واحد کامپایل در نظر گرفته می‌شوند. پیاده‌سازی‌ها تعاریف مربوط به نام‌های صادرشده توسط واحد را ارائه می‌دهند و همچنین شامل عبارت‌هایی هستند که برای اثرات جانبی‌شان ارزیابی می‌شوند. از فایل x.ml، کامپایلر ocamlopt(1) دو فایل تولید می‌کند: x.o که حاوی کد شیء بومی است، و x.cmx که حاوی اطلاعات اضافی برای پیوند دادن و بهینه‌سازی کلاینت‌های این واحد است. به پیاده‌سازی کامپایل‌شده همیشه باید با نام x.cmx ارجاع داده شود (هنگامی که یک فایل .o داده می‌شود، ocamlopt(1) فرض می‌کند که حاوی کدی است که از C کامپایل شده است، نه از OCaml).
پیاده‌سازی در برابر فایل رابط x.mli (در صورت وجود) همان‌طور که در راهنمای ocamlc(1) شرح داده شده است، بررسی می‌شود.
•
آرگومان‌هایی که به .cmx ختم می‌شوند، به عنوان کد شیء کامپایل‌شده در نظر گرفته می‌شوند. این فایل‌ها به همراه فایل‌های شیء به‌دست‌آمده از کامپایل آرگومان‌های .ml (در صورت وجود) و کتابخانه استاندارد OCaml، به یکدیگر پیوند داده می‌شوند تا یک برنامه اجرایی کد بومی تولید شود. ترتیبی که آرگومان‌های .cmx و .ml در خط فرمان ارائه می‌شوند مهم است: واحدهای کامپایل در زمان اجرا به همان ترتیب مقداردهی اولیه می‌شوند و استفاده از مؤلفه‌ای از یک واحد قبل از مقداردهی اولیه آن، خطای زمان پیوند محسوب می‌شود. بنابراین، فایل معین x.cmx باید قبل از تمام فایل‌های .cmx که به واحد x ارجاع می‌دهند، قرار گیرد.
•
آرگومان‌هایی که به .cmxa ختم می‌شوند، به عنوان کتابخانه‌های کد شیء در نظر گرفته می‌شوند. چنین کتابخانه‌ای مجموعه‌ای از فایل‌های شیء (فایل‌های .cmx/.o) را در دو فایل lib.cmxa و lib.a بسته‌بندی می‌کند. کتابخانه‌ها با ocamlopt -a ساخته می‌شوند (توضیحات مربوط به گزینه -a در زیر را ببینید). فایل‌های شیء موجود در کتابخانه به عنوان فایل‌های .cmx معمولی (بالا را ببینید) و به ترتیبی که هنگام ساخت کتابخانه مشخص شده است، پیوند داده می‌شوند. تنها تفاوت این است که اگر به فایل شیء موجود در کتابخانه در هیچ کجای برنامه ارجاع داده نشده باشد، به برنامه پیوند زده نمی‌شود.
•
آرگومان‌هایی که به .c ختم می‌شوند، به کامپایلر C ارسال می‌شوند که یک فایل شیء .o تولید می‌کند. این فایل شیء با برنامه پیوند داده می‌شود.
•
فرض می‌شود آرگومان‌هایی که به .o یا .a ختم می‌شوند، فایل‌های شیء و کتابخانه‌های C هستند. آن‌ها با برنامه پیوند داده می‌شوند.

خروجی مرحله پیوند، یک فایل اجرایی معمولی یونیکس است. این فایل برای اجرا نیازی به ocamlrun(1) ندارد.

دو نسخه از کامپایلر کد بومی وجود دارد: ocamlopt.byte یک فایل اجرایی بایت‌کد است (یعنی با ocamlc(1) کامپایل شده است)، در حالی که ocamlopt.opt یک فایل اجرایی بومی است (یعنی با خودِ ocamlopt(1) کامپایل شده است). ممکن است ocamlopt.opt در تمام نصب‌های OCaml در دسترس نباشد. ocamlopt یک نام مستعار برای نسخه سریع‌تر از بین این دو است؛ یعنی در صورت در دسترس بودن، برای ocamlopt.opt و در غیر این صورت برای ocamlopt.byte. گزینه‌های خط فرمان زیر توسط ocamlopt(1) پشتیبانی می‌شوند:

ساخت یک کتابخانه (فایل ‎.cmxa/.a) با فایل‌های شیء (فایل‌های ‎.cmx/.o) داده‌شده در خط فرمان، به‌جای پیوند دادن آن‌ها در قالب یک فایل اجرایی. نام کتابخانه باید با گزینهٔ -o تعیین شود.
اگر گزینه‌های -cclib یا -ccopt در خط فرمان مشخص شوند، این گزینه‌ها در کتابخانهٔ ‎.cmxa حاصل ذخیره می‌شوند. سپس، پیوند دادن با این کتابخانه به‌طور خودکار گزینه‌های -cclib و -ccopt را دوباره به‌گونه‌ای که در خط فرمان وارد شده باشند اعمال می‌کند، مگر اینکه گزینهٔ -noautolink داده شده باشد. علاوه بر این، زیررشتهٔ $CAMLORIGIN درون گزینه‌های -ccopt با مسیر کامل منتهی به کتابخانهٔ ‎.cma، به‌استثنای نام فایل، جایگزین خواهد شد.
نمایش نام فایل‌ها به‌صورت مسیر مطلق در پیام‌های خطا.
عدم تلاش برای نمایش نام فایل‌ها به‌صورت مسیر مطلق در پیام‌های خطا.
از نسخهٔ OCaml 4.11 منسوخ شده است. لطفاً به‌جای آن از -bin-annot استفاده کنید.
تخلیهٔ اطلاعات دقیق کامپایل (انواع، مقیدسازی‌ها، فراخوانی‌های انتهایی و غیره) در قالب باینری. اطلاعات فایل src.ml در فایل src.cmt قرار می‌گیرد. در صورت بروز خطای نوع، تمام اطلاعات استنتاج‌شده توسط بررسی‌کنندهٔ نوع پیش از وقوع خطا تخلیه می‌شود. فایل‌های حاشیه‌نویسی تولیدشده توسط -bin-annot اطلاعات بیشتری در بر دارند و نسبت به فایل‌های تولیدشده توسط -annot بسیار فشرده‌تر هستند.
فقط کامپایل. مرحلهٔ پیوند (linking) کامپایل را متوقف می‌کند. فایل‌های کد منبع به فایل‌های کامپایل‌شده تبدیل می‌شوند، اما هیچ فایل اجرایی تولید نمی‌شود. این گزینه برای کامپایل ماژول‌ها به‌صورت جداگانه کاربرد دارد.
استفاده از ccomp به‌عنوان پیونددهندهٔ C فراخوانی‌شده جهت ساخت فایل اجرایی نهایی و همچنین به‌عنوان کامپایلر C برای کامپایل فایل‌های منبع ‎.c.
ارسال گزینهٔ -llibname به پیونددهنده. این کار باعث می‌شود کتابخانهٔ C داده‌شده با برنامه پیوند بخورد.
ارسال گزینهٔ داده‌شده به کامپایلر و پیونددهندهٔ C. برای نمونه، -ccopt -Ldir باعث می‌شود پیونددهندهٔ C دایرکتوری dir را برای یافتن کتابخانه‌های C جستجو کند.
فعال یا غیرفعال کردن رنگ‌ها در پیام‌های کامپایلر (به‌ویژه هشدارها و خطاها). حالت‌های زیر پشتیبانی می‌شوند:
استفاده از روش‌های اکتشافی برای فعال‌سازی رنگ‌ها تنها در صورتی که خروجی از آن‌ها پشتیبانی کند (یک ترمینال tty سازگار با ANSI)؛
فعال‌سازی بدون قیدوشرط رنگ‌ها؛
غیرفعال کردن خروجی رنگی.
اگر -color ارائه نشده باشد، متغیر محیطی "OCAML_COLOR" بررسی می‌شود. مقادیر مجاز آن مطابق موارد فوق auto/always/never هستند.
اگر -color مشخص نشده باشد، "OCAML_COLOR" مقداردهی نشده باشد و متغیر محیطی "NO_COLOR" تنظیم شده باشد، خروجی رنگی غیرفعال می‌شود. در غیر این صورت، مقدار پیش‌فرض auto است و منطق اکتشافی فعلی بررسی می‌کند که متغیر محیطی "TERM" وجود داشته و خالی یا برابر با "dumb" نباشد و فراخوانی isatty(stderr) نیز برقرار باشد.
کنترل نحوهٔ چاپ پیام‌های خطا و هشدارها. حالت‌های زیر پشتیبانی می‌شوند:
فقط چاپ خطا و مکان آن؛
مشابه "short"، اما قطعه‌کد منبع متناظر با مکان خطا را نیز نمایش می‌دهد.
تنظیم پیش‌فرض contextual است.
اگر -error-style مشخص نشده باشد، متغیر محیطی "OCAML_ERROR_STYLE" بررسی می‌شود. مقادیر مجاز آن مطابق موارد فوق short/contextual هستند.
بهینه‌سازی کد تولیدشده از نظر حجم به جای سرعت اجرا. این امر موجب تولید برنامه‌هایی کوچک‌تر اما کمی کندتر می‌شود. حالت پیش‌فرض، بهینه‌سازی برای سرعت است.
چاپ شماره نسخهٔ ocamlopt(1) و خلاصه‌ای دقیق از پیکربندی آن، سپس خروج.
چاپ مقدار یک متغیر پیکربندی مشخص از خروجی -config و سپس خروج. اگر متغیر وجود نداشته باشد، وضعیت خروج غیرصفر خواهد بود.
محاسبهٔ وابستگی‌ها، همان‌طور که ocamldep انجام می‌دهد.
تولید یک فایل شیء (فایل‌های ‎.cmx و ‎.o) که بعداً می‌تواند به‌عنوان یک زیرماژول (با مسیر دسترسی مشخص‌شده) از یک واحد کامپایل ساخته‌شده با -pack گنجانده شود. برای نمونه، ocamlopt -for-pack P -c A.ml فایل‌های a.cmx و a.o را تولید می‌کند که بعداً می‌توانند همراه با ocamlopt -pack -o P.cmx a.cmx استفاده شوند.
افزودن اطلاعات اشکال‌زدایی هنگام کامپایل و پیوند. این گزینه برای تولید ردگیری پشته (stack backtrace) در زمان خاتمهٔ برنامه با یک استثنای مدیریت‌نشده الزامی است (ببینید: ocamlrun(1)).
عدم ثبت اطلاعات اشکال‌زدایی (پیش‌فرض).
واداشتن کامپایلر به چاپ تمام نام‌های تعریف‌شده (همراه با انواع استنتاج‌شده یا تعاریف آن‌ها) در زمان کامپایل یک پیاده‌سازی (فایل ‎.ml). هیچ فایل کامپایل‌شده‌ای (فایل‌های ‎.cmo و ‎.cmi) تولید نمی‌شود. این گزینه برای بررسی نوع‌های استنتاج‌شده توسط کامپایلر سودمند است. همچنین از آنجا که خروجی از نحو رابط‌ها پیروی می‌کند، می‌تواند در نوشتن یک رابط صریح (فایل ‎.mli) برای یک فایل به کار رود: کافی است خروجی استاندارد کامپایلر را به یک فایل ‎.mli هدایت کرده و آن فایل را برای حذف اعلان نام‌های صادرنشده ویرایش کنید.
واداشتن کامپایلر به چاپ واریانس محاسبه‌شدهٔ پارامترهای نوع برای هر اعلان نوع. بدون این گزینه، واریانس تنها برای نوع‌های خصوصی (private) یا نوع‌های بدون صورت صریح (مانند نوع‌های انتزاعی) چاپ می‌شود.
بررسی نوع پیاده‌سازی منبعِ در حال کامپایل در برابر فایل رابط مشخص‌شده (جستجوی عادی برای فایل‌های ‎.mli و ‎.cmi را دور می‌زند).
افزودن دایرکتوری داده‌شده به فهرست دایرکتوری‌های جستجو برای فایل‌های رابط کامپایل‌شده (‎.cmi)، فایل‌های کد شیء کامپایل‌شده (‎.cmx) و کتابخانه‌ها (‎.cmxa). به‌طور پیش‌فرض، ابتدا دایرکتوری جاری و سپس دایرکتوری کتابخانهٔ استاندارد جستجو می‌شود. دایرکتوری‌های اضافه‌شده با -I پس از دایرکتوری جاری، به همان ترتیبی که در خط فرمان داده شده‌اند، اما پیش از دایرکتوری کتابخانهٔ استاندارد جستجو می‌شوند. همچنین گزینهٔ -nostdlib را ببینید.
اگر دایرکتوری داده‌شده با + شروع شود، مسیر آن نسبت به دایرکتوری کتابخانهٔ استاندارد در نظر گرفته می‌شود. برای نمونه، -I +compiler-libs زیردایرکتوری compiler-libs از کتابخانهٔ استاندارد را به مسیر جستجو اضافه می‌کند..TP -impl filename فایل filename را به عنوان یک فایل پیاده‌سازی کامپایل می‌کند، حتی اگر پسوند آن .ml نباشد.
میزان تهاجمی بودن درون‌خطی‌سازی (inlining) را روی n تنظیم می‌کند، که در آن n یک عدد صحیح مثبت است. مشخص کردن -inline 0 از درون‌خطی شدن تمام توابع جلوگیری می‌کند، به جز توابعی که بدنه آن‌ها از محل فراخوانی کوچک‌تر است. بنابراین، درون‌خطی‌سازی موجب افزایش اندازه کد نمی‌شود. مقدار تهاجمی پیش‌فرض، -inline 1، اجازه می‌دهد توابع کمی بزرگ‌تر نیز درون‌خطی شوند که منجر به افزایش جزئی در اندازه کد می‌شود. مقادیر بالاتر برای گزینه -inline باعث می‌شوند توابع بزرگ‌تر و بزرگ‌تری کاندید درون‌خطی‌سازی شوند، اما می‌تواند منجر به افزایش چشمگیر اندازه کد شود.
گذر زمان‌بندی دستورالعمل‌ها را در بخش پشتی (backend) کامپایلر فعال می‌کند.
فایل filename را به عنوان یک فایل رابط (interface) کامپایل می‌کند، حتی اگر پسوند آن .mli نباشد.
-intf-suffix string
نام‌های فایلی را که به string ختم می‌شوند، به عنوان فایل‌های رابط شناسایی می‌کند (به جای پسوند پیش‌فرض .mli).
رشته‌های مستندات را در فایل‌های .cmi تولیدشده نگه می‌دارد.
موقعیت‌ها را در فایل‌های .cmi تولیدشده نگه می‌دارد.
برچسب‌ها در نوع‌ها نادیده گرفته نمی‌شوند، می‌توان از برچسب‌ها در فراخوانی‌ها استفاده کرد، و پارامترهای برچسب‌دار را می‌توان با هر ترتیبی ارائه داد. این حالت پیش‌فرض است.
پیوند دادن تمامی پودمان‌های موجود در کتابخانه‌ها را اجباری می‌کند. اگر این پرچم مشخص نشود، پودمان‌های بدون ارجاع پیوند داده نمی‌شوند. هنگام ساخت یک کتابخانه (پرچم -a)، تنظیم پرچم -linkall تمام پیوندهای بعدی برنامه‌های مرتبط با آن کتابخانه را مجبور می‌کند تا همه پودمان‌های موجود در کتابخانه را پیوند دهند. هنگام کامپایل یک پودمان (گزینه -c)، تنظیم گزینه -linkall تضمین می‌کند که این پودمان در صورت قرار گرفتن در یک کتابخانه و پیوند خوردن آن کتابخانه، همواره پیوند داده خواهد شد.
از تخصیص ثبات با پیمایش خطی (linear scan) استفاده می‌کند. کامپایل با این تخصیص‌دهنده سریع‌تر از تخصیص‌دهنده معمول رنگ‌آمیزی گراف است، که گاهی برای توابع طولانی و پودمان‌ها بسیار چشمگیر است. از سوی دیگر، کد تولیدشده ممکن است کمی کندتر باشد.
تعداد سطرهای زمینه مورد استفاده در طول کامپایل تطبیق الگو (pattern matching) را تعیین می‌کند. مقادیر کمتر موجب کامپایل سریع‌تر اما کد کمتر بهینه‌شده می‌شوند. مقدار پیش‌فرض ۳۲ است.
وابستگی‌ها را برای نام‌های مستعار پودمان ثبت نمی‌کند.
رفتار کاربردی (applicative) فانکتورها را غیرفعال می‌کند. با این گزینه، هر بار اعمال فانکتور نوع‌های جدیدی در نتیجه خود تولید می‌کند و اعمال دوباره همان فانکتور روی یک آرگومان یکسان، دو ساختار ناسازگار ایجاد می‌کند.
بررسی‌های تصدیق (assertion) را کامپایل نمی‌کند. توجه داشته باشید که شکل ویژه assert false همیشه کامپایل می‌شود زیرا نوع‌بندی ویژه‌ای دارد. این پرچم هنگام پیوند فایل‌های از پیش کامپایل‌شده هیچ تاثیری ندارد.
هنگام پیوند کتابخانه‌های .cmxa، گزینه‌های -cclib و -ccopt را که احتمالاً در کتابخانه‌ها وجود دارند (اگر این گزینه‌ها در زمان ساخت کتابخانه‌ها داده شده باشند) نادیده می‌گیرد. این می‌تواند در صورتی مفید باشد که یک کتابخانه حاوی مشخصات نادرستی از کتابخانه‌های C یا گزینه‌های C باشد؛ در این حالت، هنگام پیوند، -noautolink را تنظیم کرده و کتابخانه‌ها و گزینه‌های صحیح C را در خط فرمان وارد کنید.
به کامپایلر اجازه می‌دهد تا از بهینه‌سازی‌هایی استفاده کند که فقط برای کدهایی معتبر هستند که هرگز پیوند پویا (dynlink) نمی‌شوند.
گذر زمان‌بندی دستورالعمل‌ها را در بخش پشتی (backend) کامپایلر غیرفعال می‌کند.
دایرکتوری کتابخانه استاندارد را به صورت خودکار به فهرست دایرکتوری‌های جستجو برای فایل‌های رابط کامپایل‌شده (.cmi)، فایل‌های کد شیء کامپایل‌شده (.cmx) و کتابخانه‌ها (.cmxa) اضافه نمی‌کند. همچنین گزینه -I را ببینید.
برچسب‌های غیر اختیاری را در نوع‌ها نادیده می‌گیرد. برچسب‌ها نمی‌توانند در فراخوانی‌ها استفاده شوند و ترتیب پارامترها سخت‌گیرانه می‌شود.
نام فایل خروجی نهایی را مشخص می‌کند، خواه یک فایل اجرایی باشد، یک شیء کامپایل‌شده (گزینه -c)، یک کتابخانه (گزینه -a)، یک شیء بسته‌بندی‌شده (گزینه -pack)، یک پلاگین با امکان پیوند پویا (گزینه -shared) یا یک فایل منبع یا شیء C (گزینه‌های -output-obj و -output-complete-obj).
نام خروجی پیش‌فرض برای یک فایل اجرایی به پلتفرم بستگی دارد؛ در یونیکس a.out و در ویندوز camlprog.exe است.
این مورد همچنین می‌تواند هنگام کامپایل اما بدون پیوند یک فایل رابط یا پیاده‌سازی (گزینه -c) استفاده شود، که در این صورت هم نام فایل cmi یا cmx و هم نام واحد کامپایل را تا اولین نقطه به filename تنظیم می‌کند.
هنگام کامپایل یک فایل رابط .mli، اثری مشابه با گزینه -opaque در کامپایلر بایت‌کد دارد. هنگام کامپایل یک فایل پیاده‌سازی .ml، یک فایل .cmx بدون اطلاعات بهینه‌سازی بین‌پودمانی تولید می‌کند، که کامپایل مجدد در زمان تغییر پودمان را کاهش می‌دهد.
پودمان داده‌شده را پیش از پردازش فایل‌های رابط یا پیاده‌سازی باز می‌کند. اگر چندین گزینه -open داده شود، آن‌ها به ترتیب پردازش می‌شوند، درست مانند این‌که عبارات open! module1;; ... open! moduleN;; در بالای هر فایل اضافه شده باشند.
باعث می‌شود پیونددهنده به جای یک فایل اجرایی، یک فایل شیء C تولید کند. این برای بسته‌بندی کد OCaml به شکل یک کتابخانه C که از هر برنامه C قابل فراخوانی باشد مفید است. نام فایل شیء خروجی باید با گزینه -o تعیین شود. این گزینه همچنین می‌تواند برای تولید یک کتابخانه مشترک/پویا کامپایل‌شده (با پسوند .so) استفاده شود.
مشابه -output-obj است، با این تفاوت که فایل شیء تولیدشده شامل زمان اجرا (runtime) و کتابخانه‌های پیوند خودکار (autolink) نیز می‌باشد.
یک فایل شیء (فایل‌های .cmx و .o) و رابط کامپایل‌شده مرتبط با آن (.cmi) ایجاد می‌کند که فایل‌های شیء .cmx داده‌شده در خط فرمان را ترکیب کرده و آن‌ها را به صورت زیرپودمان‌های فایل .cmx خروجی در می‌آورد. نام فایل .cmx خروجی باید با گزینه -o مشخص شود. برای نمونه، ocamlopt -pack -o P.cmx A.cmx B.cmx C.cmx فایل‌های کامپایل‌شده P.cmx، P.o و P.cmi را تولید می‌کند که توصیف‌کننده یک واحد کامپایل با سه زیرپودمان A، B و C متناظر با محتویات فایل‌های شیء A.cmx، B.cmx و C.cmx هستند. این محتویات را می‌توان در ادامه برنامه به عنوان P.A، P.B و P.C ارجاع داد.
فایل‌های شیء .cmx که ترکیب می‌شوند باید با گزینه مناسب -for-pack کامپایل شده باشند. در مثال بالا، A.cmx، B.cmx و C.cmx باید با ocamlopt -for-pack P کامپایل شده باشند.
سطوح چندگانه بسته‌بندی را می‌توان با ترکیب -pack با -for-pack به دست آورد. برای جزئیات بیشتر، به The OCaml user's manual، فصل "Native-code compilation" مراجعه کنید..TP -pp command باعث می‌شود کامپایلر command مشخص‌شده را به عنوان یک پیش‌پردازنده برای هر فایل سورس فراخوانی کند. خروجیِ command به یک فایل میانی هدایت می‌شود که سپس کامپایل خواهد شد. اگر خطایی در کامپایل رخ ندهد، فایل میانی پس از آن حذف می‌شود.
پس از تجزیه (parsing)، درخت نحو انتزاعی (AST) را از میان پیش‌پردازندهٔ command عبور می‌دهد (pipe می‌کند). ماژول Ast_mapper(3) رابط خارجی یک پیش‌پردازنده را پیاده‌سازی می‌کند.
مسیر اطلاعات را در طول بررسی نوع (type-checking) بررسی می‌کند تا اطمینان حاصل شود که تمام نوع‌ها به روش بنیادین (principal) استنتاج شده‌اند. تمام برنامه‌های پذیرفته‌شده در حالت -principal در حالت پیش‌فرض نیز با نوع‌های معادل اما امضاهای باینری متفاوت پذیرفته می‌شوند.
بنیادین بودن (principality) استنتاج نوع را بررسی نمی‌کند. این مقدار پیش‌فرض است.
نوع‌های بازگشتی دلخواه را در طول بررسی نوع مجاز می‌کند. به‌طور پیش‌فرض، تنها نوع‌های بازگشتی که بازگشت در آن‌ها از طریق یک نوع شیء (object type) انجام می‌شود پشتیبانی می‌شوند. توجه داشته باشید که پس از ایجاد یک رابط با استفاده از این پرچم، باید آن را مجدداً برای تمام وابستگی‌ها به کار ببرید.
نوع‌های بازگشتی دلخواه را در طول بررسی نوع مجاز نمی‌کند. این مقدار پیش‌فرض است.
پسوند suffix را به نام کتابخانه زمان‌اجرا (runtime library) که توسط برنامه استفاده خواهد شد اضافه می‌کند. اگر OCaml با گزینهٔ -with-debug-runtime پیکربندی شده باشد، پسوند d پشتیبانی می‌شود و نسخه دیباگ زمان‌اجرا را ارائه می‌دهد.
کد اسمبلی تولیدشده در حین کامپایل را نگه می‌دارد. کد اسمبلی برای فایل سورس x.ml در فایل x.s ذخیره می‌شود.
جداسازی بین نوع‌های string و bytes را اعمال می‌کند، و در نتیجه رشته‌ها فقط‌خواندنی می‌شوند. این مقدار پیش‌فرض است.
از اطلاعات نوع برای بهینه‌سازی تطبیق الگو (pattern-matching) استفاده نمی‌کند. این کار امکان تشخیص شکست‌های تطبیق را فراهم می‌آورد حتی اگر یک تطبیق الگو به‌اشتباه جامع (exhaustive) در نظر گرفته شده باشد. این مورد تنها بر کامپایل GADT و واریانت‌های چندریختی تأثیر می‌گذارد.
نمایش میانی (IR) را پس از گذر (pass) کامپایل داده‌شده ذخیره می‌کند. گذرهای پشتیبانی‌شده در حال حاضر عبارتند از: scheduling.
هنگام پیوند دادن یک فایل اجرایی، مقدار پیش‌فرض یک تنظیم زمان‌اجرا را بازنویسی می‌کند. تنها تنظیم پشتیبانی‌شده در حال حاضر عبارت است از:
مکان پیش‌فرضی را مشخص می‌کند که توسط فایل اجرایی برای مکان‌یابی کتابخانه استاندارد استفاده می‌شود. به‌طور پیش‌فرض، این مسیر مطلقِ کتابخانه استانداردی است که کامپایلر با آن پیکربندی شده بود.
یک پلاگین (معمولاً ‎.cmxs) می‌سازد که می‌تواند به صورت پویا با ماژول Dynlink بارگذاری شود. نام پلاگین باید با گزینهٔ -o مشخص شود. یک پلاگین می‌تواند شامل تعدادی ماژول و کتابخانهٔ OCaml و آبجکت‌های محلی اضافی (فایل‌های ‎.o،‏ ‎.a) باشد. ساخت پلاگین‌های بومی (native) تنها برای برخی سیستم‌عامل‌ها پشتیبانی می‌شود. در برخی سیستم‌ها (در حال حاضر، فقط Linux AMD 64)، تمام کدهای OCaml پیوندشده در یک پلاگین باید بدون پرچم -nodynlink کامپایل شده باشند. همچنین ممکن است محدودیت‌هایی برای نحوه کامپایل آبجکت‌های محلی اضافی اعمال شود (در Linux AMD 64، آن‌ها باید تنها حاوی کد مستقل از موقعیت یا PIC باشند).
-short-paths
هنگامی که یک نوع در چند مسیر ماژول قابل مشاهده است، هنگام چاپ نام نوع در رابط‌های استنتاج‌شده و پیام‌های خطا و هشدار، از کوتاه‌ترین مسیر استفاده می‌کند.
کامپایل را پس از گذرِ کامپایل مشخص‌شده متوقف می‌کند. گذرهای پشتیبانی‌شده در حال حاضر عبارتند از: parsing, typing, scheduling, emit.
بخش سمت چپ یک توالی (sequence) باید از نوع unit باشد.
بخش سمت چپ یک توالی نیازی نیست که از نوع unit باشد. این مقدار پیش‌فرض است.
هنگامی که یک نوع unboxable باشد (یعنی یک رکورد با یک آرگومان منفرد یا یک نوع داده ملموس با یک سازندهٔ تک‌آرگومانی)، unbox خواهد شد مگر اینکه با [@@ocaml.boxed] نشانه‌گذاری شده باشد.
هنگامی که یک نوع unboxable باشد، به‌صورت boxed درمی‌آید مگر اینکه با [@@ocaml.unboxed] نشانه‌گذاری شده باشد. این مقدار پیش‌فرض است.
بررسی محدوده (bound checking) را برای دسترسی به آرایه‌ها و رشته‌ها (ساختارهای v.(i) و s.[i]) غیرفعال می‌کند. بنابراین برنامه‌های کامپایل‌شده با -unsafe سریع‌تر هستند، اما ناامن: اگر برنامه به یک آرایه یا رشته خارج از محدوده‌اش دسترسی پیدا کند، هر اتفاقی ممکن است رخ دهد. علاوه بر این، بررسی تقسیم بر صفر در عملیات تقسیم صحیح و باقی‌مانده را خاموش می‌کند. با -unsafe، تقسیم صحیح (یا باقی‌مانده) بر صفر می‌تواند به جای برانگیختن استثنای Division_by_zero ، برنامه را متوقف کند یا با یک نتیجه نامشخص ادامه دهد.
-unsafe-string
نوع‌های string و bytes را یکی در نظر می‌گیرد، و در نتیجه رشته‌ها قابل‌نوشتن می‌شوند. این گزینه برای سازگاری با سورس کدهای قدیمی در نظر گرفته شده است و نباید در نرم‌افزارهای جدید استفاده شود.
شماره نسخه کامپایلر و مکان دایرکتوری کتابخانه استاندارد را چاپ کرده و سپس خارج می‌شود.
همه دستورهای خارجی را قبل از اجرا چاپ می‌کند، به‌ویژه فراخوانی‌های اسمبلی، کامپایلر C و پیونددهنده (linker).
شماره نسخه کامپایلر را به شکل کوتاه (مثلاً "3.11.0") چاپ کرده و سپس خارج می‌شود.
هشدارهای مشخص‌شده توسط آرگومان warning-list را فعال یا غیرفعال کرده، یا به عنوان مهلک (fatal) علامت‌گذاری می‌کند. برای مستندات کامل این پرچم، به‌ویژه فهرست هشدارهای پشتیبانی‌شده، ocamlc(1) را ببینید.
هشدارهای مشخص‌شده در آرگومان warning-list را به عنوان مهلک (fatal) علامت‌گذاری می‌کند. وقتی یکی از این هشدارها صادر شود، کامپایلر با یک خطا متوقف خواهد شد. آرگومان warning-list معنایی مشابه با گزینهٔ -w دارد: علامت + (یا یک حرف بزرگ) هشدارهای متناظر را مهلک می‌کند، علامت - (یا یک حرف کوچک) آن‌ها را دوباره به هشدارهای غیرمهلک تبدیل می‌کند، و علامت @ هشدارهای مربوطه را هم فعال کرده و هم به عنوان مهلک علامت می‌زند.
نکته: استفاده از گزینهٔ -warn-error در کد محیط عملیاتی (production) توصیه نمی‌شود، زیرا زمانی که نسخه‌های بعدی OCaml هشدارهای جدیدی اضافه کنند یا هشدارهای موجود را تغییر دهند، تقریباً به طور حتم مانع از کامپایل برنامه شما خواهد شد.
تنظیم پیش‌فرض -warn-error -a است (هیچ هشداری مهلک نیست).
توضیحات تمام شماره‌های هشدار موجود را نمایش می‌دهد..TP -where نمایش مسیر کتابخانهٔ استاندارد و سپس خروج.
گنجاندن سامانهٔ زمان‌اجرا در برنامهٔ تولیدشده. این گزینه پیش‌فرض است.
کامپایلر سامانهٔ زمان‌اجرا (و نیز ارجاع به آن) را در برنامهٔ تولیدشده نمی‌گنجاند؛ این سامانه باید به‌صورت جداگانه فراهم شود.
- file
پردازش file به‌عنوان نام فایل، حتی اگر با نویسهٔ خط تیره (-) آغاز شود.
نمایش خلاصهٔ کوتاهی از کاربرد دستور و خروج.

هنگامی که تولیدکنندهٔ کد Flambda در زمان پیکربندی فعال شده باشد، رفتار آن را می‌توان با گزینه‌های اضافی زیر تنظیم کرد:

انجام بهینه‌سازی بیش از حد معمول. زمان کامپایل ممکن است طولانی‌تر شود.
انجام بهینه‌سازی حتی بیش از حد معمول، احتمالاً شامل باز کردن (unrolling) توابع بازگشتی. زمان کامپایل ممکن است به‌طور چشمگیری طولانی‌تر شود.
تصمیم‌گیری دربارهٔ درون‌خطی‌سازی (inlining) را در محل تعریف تابع انجام می‌دهد، نه در محل(های) فراخوانی آن. این ویژگی رفتار کامپایلرهای OCaml را که از Flambda استفاده نمی‌کنند بازتاب می‌دهد. در مقایسه با کامپایل با استفاده از روش‌های ابتکاری جدید درون‌خطی‌سازی Flambda (برای نمونه در -O2)، این گزینه فایل‌های .cmx کوچک‌تر، زمان کامپایل کوتاه‌تر و کدی تولید می‌کند که احتمالاً تا حدی کندتر اجرا می‌شود.
تولید فایل‌های .inlining (یک فایل به ازای هر دور بهینه‌سازی) که تمامی تصمیم‌های درون‌خطی‌ساز (inliner) را نمایش می‌دهد.

تولیدکنندهٔ کد AMD64 (نسخه‌های ۶۴ بیتی Intel Pentium و AMD Athlon) از گزینه‌های اضافی زیر پشتیبانی می‌کند:

تولید کد ماشین مستقل از موقعیت (position-independent). این گزینه پیش‌فرض است.
تولید کد ماشین وابسته به موقعیت (position-dependent).

ocamlc(1).
The OCaml user's manual, فصل «Native-code compilation».