tup [--debug-sql] [--debug-fuse] [SECONDARY_COMMAND] [ARGS]

-jN

به طور موقت گزینه updater.num_jobs را با مقدار 'N' بازنویسی می‌کند. این کار با توجه به محدودیت‌های گراف جهت‌دار غیرمدور (DAG)، تا N وظیفه را به صورت موازی اجرا خواهد کرد. به عنوان مثال: 'tup -j2' تا دو وظیفه را به طور موازی اجرا می‌کند، در حالی که 'tup' تا میزان تعیین‌شده در updater.num_jobs وظیفه موازی اجرا خواهد کرد. دستور ثانویه option را در ادامه ببینید.

--verbose

باعث می‌شود tup به جای نمایش رشته ساده‌شده، رشته کامل دستور را برای دستوراتی که از پیشوند ^ TEXT^ استفاده می‌کنند، نمایش دهد.

--quiet

به طور موقت گزینه display.quiet را به '1' تغییر می‌دهد. دستور ثانویه option را در ادامه ببینید.

-k

--keep-going

به طور موقت گزینه updater.keep_going را به '1' تغییر می‌دهد. دستور ثانویه option را در ادامه ببینید.

--no-keep-going

به طور موقت گزینه updater.keep_going را به '0' تغییر می‌دهد. دستور ثانویه option را در ادامه ببینید.

--no-scan

پروژه را برای یافتن فایل‌های تغییریافته پویش نمی‌کند. این گزینه صرفاً برای آزمایش‌های داخلی tup است و نباید در توسعه معمول استفاده شود.

--no-environ-check

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

-d

خروجی گزارش اشکال‌زدایی را روی صفحه نمایش می‌دهد.

--debug-run

قواعد :- تولیدشده توسط یک run-script را نمایش می‌دهد. ویژگی 'run ./script args' را در بخش TUPFILES ببینید. --debug-logging بخشی از خروجی‌های اشکال‌زدایی و گراف‌های ساخت را در .tup/log ذخیره می‌کند. گراف‌ها در هر بار فراخوانی همراه با --debug-logging چرخش (rotate) می‌یابند.

--no-sync

گزینه 'db.sync' پروژه را روی '0' تنظیم می‌کند. به طور پیش‌فرض گزینه 'db.sync' برابر با '1' است. این پرچم عمدتاً برای موارد آزمایشی کاربرد دارد، اما می‌توانید در هر محیطی که مایلید برای tup اسکریپت‌نویسی کنید و به صورت پیش‌فرض از همگام‌سازی استفاده نکنید نیز از آن بهره ببرید.

-d

اشکال‌زدایی فرآیند پایشگر را فعال می‌کند.

-f

--foreground

به طور موقت گزینه monitor.foreground را به 1 تغییر می‌دهد. پایشگر در پیش‌زمینه اجرا خواهد شد (دیمن نمی‌شود).

-b

--background

به طور موقت گزینه monitor.foreground را به 0 تغییر می‌دهد. پایشگر در پس‌زمینه اجرا خواهد شد (دیمن می‌شود).

-a

--autoupdate

به طور موقت گزینه monitor.autoupdate را به 1 تغییر می‌دهد. این گزینه هنگام تشخیص تغییرات فایل‌ها، به طور خودکار فرآیند به‌روزرسانی را اجرا می‌کند.

-n

--no-autoupdate

به طور موقت گزینه monitor.autoupdate را به 0 تغییر می‌دهد. این کار از اجرای خودکار به‌روزرسانی توسط پایشگر هنگام تشخیص تغییرات فایل‌ها جلوگیری می‌کند.

--autoparse

--autoparse

به طور موقت گزینه monitor.autoparse را به 1 تغییر می‌دهد. این گزینه هنگام تشخیص تغییرات فایل‌ها، به طور خودکار تجزیه‌کننده را اجرا می‌کند.

--no-autoparse

به طور موقت گزینه monitor.autoparse را به 0 تغییر می‌دهد. این کار از اجرای خودکار تجزیه‌کننده توسط پایشگر هنگام تشخیص تغییرات فایل‌ها جلوگیری می‌کند.

--dirs

به طور موقت گزینه graph.dirs را روی '1' بازنویسی می‌کند. این کار گره‌های دایرکتوری و Tupfileها را نمایش می‌دهد.

--ghosts

به طور موقت گزینه graph.ghosts را روی '1' بازنویسی می‌کند. این کار گره‌های شبح (فایل‌هایی که یک دستور تلاش کرده به آن‌ها دسترسی پیدا کند اما وجود ندارند) را نشان می‌دهد.

--env

به طور موقت گزینه graph.environment را روی '1' بازنویسی می‌کند. این کار متغیرهای محیطی نظیر PATH را نشان می‌دهد.

--no-scan

پروژه را برای یافتن فایل‌های تغییریافته پویش نمی‌کند. این گزینه فقط برای آزمایش‌های داخلی tup است و نباید در توسعه معمول استفاده شود.

--verbose

باعث می‌شود tup به جای نمایش رشته ساده‌شده، رشته کامل دستور را برای دستوراتی که از پیشوند ^ TEXT^ استفاده می‌کنند، نمایش دهد.

command-line overrides (eg: -j flag passed to 'tup')
.tup/options file
~/.tupoptions file
/etc/tup/options file
tup's compiled in defaults

command-line overrides
.tup/options file
tup.ini in the Application Data path (usually C:\ProgramData\tup\tup.ini)
tup's compiled in defaults

[updater]

[updater]
	num_jobs = 2
	keep_going = true

db.sync (پیش‌فرض '1')

اگر ویژگی synchronous مربوط به SQLite فعال باشد، روی '1' تنظیم می‌شود. هنگامی که فعال باشد، پایگاه‌داده به درستی با دیسک همگام‌سازی می‌شود به گونه‌ای که همواره سازگار و یکپارچه باقی می‌ماند. هنگامی که غیرفعال باشد، برنامه سریع‌تر اجرا می‌شود زیرا عملیات نوشتن برای مدتی پیش از تخلیه روی دیسک در حافظهٔ نهان می‌ماند. با این حال، اگر رایانهٔ شما پیش از نوشته شدن کامل اطلاعات دچار کرش شود، ممکن است پایگاه‌دادهٔ tup خراب شود. برای اطلاعات بیشتر http://www.sqlite.org/pragma.html را ببینید.

updater.num_jobs (پیش‌فرض برابر با تعداد پردازنده‌های سیستم)

روی بیشینهٔ تعداد دستوراتی که tup به‌طور هم‌زمان اجرا خواهد کرد تنظیم می‌شود. پیش‌فرض به‌طور پویا بر اساس تعداد پردازنده‌های موجود در سیستم تعیین می‌شود. اگر updater.num_jobs بزرگ‌تر از 1 باشد، دستورات تنها در صورتی به صورت موازی اجرا می‌شوند که مستقل از یکدیگر باشند. همچنین گزینهٔ -j را ببینید.

updater.keep_going (پیش‌فرض '0')

روی '1' تنظیم کنید تا حتی در صورت بروز خطا، فرایند ساخت تا جای ممکن ادامه یابد. هر چیزی که وابسته به یک دستور شکست‌خورده باشد اجرا نخواهد شد، اما سایر دستورات مستقل اجرا می‌شوند. پیش‌فرض '0' است که باعث می‌شود tup پس از نخستین دستور شکست‌خورده متوقف شود. همچنین گزینهٔ -k را ببینید.

updater.full_deps (پیش‌فرض '0')

روی '1' تنظیم کنید تا وابستگی‌ها به فایل‌های خارج از سلسله‌مراتب tup نیز ردگیری شوند. پیش‌فرض '0' است که تنها وابستگی‌های درون سلسله‌مراتب tup را ردگیری می‌کند. برای نمونه، اگر می‌خواهید با به‌روزرسانی gcc در سیستم، تمامی فایل‌های C دوباره کامپایل شوند، باید این مقدار را روی '1' قرار دهید. در Linux و OSX، استفاده از وابستگی‌های کامل مستلزم این است که باینری tup دارای دسترسی suid به عنوان کاربر root باشد تا بتواند زیرفرایندها را در محیط chroot اجرا کند. همچنین در Linux، اگر هستهٔ شما از user namespaces پشتیبانی کند، نیازی به suid کردن باینری نخواهید داشت. توجه داشته باشید که اگر این مقدار از '0' به '1' تغییر کند، tup کل پروژه را دوباره خواهد ساخت. غیرفعال کردن این گزینه در صورتی که قبلاً فعال بوده باشد، نیازی به بازسازی کامل ندارد اما مدتی زمان می‌برد، چرا که گره‌های نمایانگر فایل‌های خارجی پاک‌سازی می‌شوند. توجه: این قابلیت در حال حاضر به دلیل مسائل مربوط به قفل‌گذاری، با ccache یا سایر برنامه‌هایی که ممکن است در فایل‌های خارجی بنویسند کار نمی‌کند. این موضوع ممکن است در آینده رفع شود.

updater.warnings (پیش‌فرض '1')

روی '0' تنظیم کنید تا هشدارهای مربوط به نوشتن در فایل‌های پنهان غیرفعال شوند. tup فایل‌های پنهان را ردگیری نمی‌کند. اگر یک زیرفرایند در فایلی پنهان بنویسد، tup به‌طور پیش‌فرض هشداری مبنی بر ایجاد این فایل نمایش می‌دهد. با غیرفعال کردن این گزینه، این هشدارها نمایش داده نمی‌شوند. نام فایل‌ها (یا دایرکتوری‌های) پنهان شامل موارد زیر است: .، ..، .tup، .git، .hg، .bzr، .svn.

display.color (پیش‌فرض 'auto')

روی 'never' تنظیم کنید تا کدهای فرار ANSI برای خروجی رنگی غیرفعال شوند، یا روی 'always' تنظیم کنید تا همواره از کدهای فرار ANSI برای خروجی رنگی استفاده شود. مقدار پیش‌فرض 'auto' است که اگر خروجی استاندارد (stdout) به یک tty متصل باشد از خروجی رنگی استفاده می‌کند و در غیر این صورت رنگی به کار نمی‌برد (یعنی اگر خروجی استاندارد به یک فایل هدایت شده باشد).

display.width (پیش‌فرض برابر با عرض ترمینال)

برای اعمال یک عرض ثابت برای نوار پیشرفت، آن را روی هر عدد ۱۰ یا بزرگ‌تر تنظیم کنید. این مقدار به عنوان عرض کل در نظر گرفته می‌شود که بخشی از آن برای فاصله‌گذاری، قلاب‌ها و درصد پیشرفت استفاده می‌شود. اگر این مقدار کمتر از ۱۰ باشد، نوار پیشرفت غیرفعال می‌شود.

display.progress (پیش‌فرض '1' در صورتی که stdout یک TTY باشد)

روی '1' تنظیم کنید تا نوار پیشرفت فعال شود، یا '0' برای خاموش کردن آن. به‌طور پیش‌فرض اگر خروجی استاندارد یک TTY باشد فعال و اگر خروجی استاندارد TTY نباشد غیرفعال است.

display.job_numbers (پیش‌فرض '1')

روی '0' تنظیم کنید تا از نمایش رشتهٔ "N) " پیش از نتایج یک کار جلوگیری شود. حالت پیش‌فرض نمایش این شماره است.

display.job_time (پیش‌فرض '1')

روی '0' تنظیم کنید تا از نمایش زمان اجرای کار در کنار نتایج خودداری شود. حالت پیش‌فرض نمایش زمان اجرا است. توجه داشته باشید زمان اجرای نمایش‌داده‌شده شامل زمانی است که tup برای ذخیرهٔ وابستگی‌ها صرف می‌کند. بنابراین، این زمان اجرا احتمالاً بیشتر از زمان اجرای دستی همان کار در شل خواهد بود.

display.quiet (پیش‌فرض '0')

روی '1' تنظیم کنید تا از نمایش بخش عمدهٔ خروجی توسط tup جلوگیری شود. tup همچنان بنر و خروجی مربوط به هر کاری را که در stdout/stderr می‌نویسد، یا هر کاری را که کد خروج غیرصفر بازمی‌گرداند، نمایش خواهد داد. نوار پیشرفت همچنان نمایش داده می‌شود؛ همچنین display.progress را برای خروجی کاملاً بی‌صدا ببینید.

monitor.autoupdate (پیش‌فرض '0')

روی '1' تنظیم کنید تا در صورت تشخیص تغییر در فایل‌ها، بازسازی به‌طور خودکار انجام شود. این مورد تنها در صورتی اثرگذار است که ناظر (monitor) در حال اجرا باشد. مقدار پیش‌فرض '0' است، به این معنی که هر زمان آمادهٔ به‌روزرسانی بودید باید 'tup' را تایپ کنید.

monitor.autoparse (پیش‌فرض '0')

روی '1' تنظیم کنید تا در صورت تشخیص تغییر در فایل‌ها، تجزیه‌کننده به‌طور خودکار اجرا شود. این مورد مشابه monitor.autoupdate است، با این تفاوت که به‌روزرسانی پس از مرحلهٔ تجزیه متوقف می‌شود و تا زمانی که به‌طور دستی 'tup' را تایپ نکنید هیچ دستوری اجرا نمی‌شود. این گزینه تنها زمانی اثر دارد که monitor در حال اجرا باشد. توجه داشته باشید که اگر هر دو گزینهٔ autoupdate و autoparse تنظیم شده باشند، autoupdate اولویت خواهد داشت.

monitor.foreground (پیش‌فرض '0')

روی '1' تنظیم کنید تا ناظر در پیش‌زمینه اجرا شود؛ به این ترتیب کنترل تا زمانی که ناظر متوقف نشود به ترمینال برنمی‌گردد (چه از طریق ctrl-C در ترمینال جاری، چه با اجرای 'tup stop' در یک ترمینال دیگر). پیش‌فرض '0' است که یعنی ناظر در پس‌زمینه اجرا خواهد شد.

graph.dirs (پیش‌فرض '0')

روی '1' تنظیم کنید تا دستور 'tup graph' گره‌های دایرکتوری و پیوندهای مالکیت آن‌ها را نمایش دهد. Tupfileها نیز نمایش داده می‌شوند، چرا که به گره‌های دایرکتوری اشاره دارند. به‌طور پیش‌فرض دایرکتوری‌ها و Tupfileها نمایش داده نمی‌شوند زیرا در برخی موارد می‌توانند گراف را شلوغ کنند و همیشه مفید نیستند.

graph.ghosts (پیش‌فرض '0')

روی '1' تنظیم کنید تا گره‌های شبح (ghost nodes) نمایش داده شوند. برخی دستورها ممکن است تلاش کنند فایل‌های ناموجود متعددی را بخوانند که باعث ایجاد گره‌های شبح می‌شود. به‌طور پیش‌فرض، شبح‌ها نمایش داده نمی‌شوند تا درک گراف ساده‌تر باشد.

graph.environment (پیش‌فرض '0')

روی '1' تنظیم کنید تا گره‌های محیطی (مانند PATH) و وابستگی‌های آن‌ها نمایش داده شوند. به‌طور پیش‌فرض متغیرهای محیطی نمایش داده نمی‌شوند زیرا تقریباً همه چیز به PATH وابسته خواهد بود.

graph.combine (پیش‌فرض '0')

روی '1' تنظیم کنید تا سعی شود گره‌های مشابه در گراف با یکدیگر ترکیب شوند. به عنوان مثال، به جای نمایش ۱۰ دستور کامپایل مجزا که همگی یک ورودی فایل .c و یک خروجی فایل .o دارند، این گزینه آن‌ها را در قالب یک دستور ادغام می‌کند تا دیدن ساختار کلی گراف آسان‌تر شود. به‌طور پیش‌فرض تمام گره‌ها به صورت جداگانه نمایش داده می‌شوند. هر جا در سلسله‌مراتب tup که می‌خواهید بر اساس فایل‌های ورودی یک فایل خروجی ایجاد کنید، باید فایلی به نام «Tupfile» ایجاد نمایید. فایل‌های ورودی می‌توانند در هر جای دیگری از سلسله‌مراتب tup قرار داشته باشند، اما فایل(های) خروجی باید در همان دایرکتوری Tupfile نوشته شوند.

: [foreach] [inputs] [ | order-only inputs] |> command |> [outputs] [ | extra outputs] [<group>] [{bin}]

قواعد : (یا :-rules) ابزار اصلی برای ایجاد دستورها هستند و با قرار گرفتن نویسهٔ «:» در ستون اول Tupfile مشخص می‌شوند. نحوِ دستور به‌گونه‌ای طراحی شده که شبیه یک خط‌لوله (pipeline) به نظر برسد؛ به این صورت که فایل‌های ورودی در سمت چپ وارد دستورِ میانی شده و فایل‌های خروجی در سمت راست تولید می‌شوند.

^-flags

در رشتهٔ دستوری که از توالی ^ TEXT^ استفاده می‌کند، نویسه‌های پرچم می‌توانند بلافاصله پس از ^ تا اولین نویسهٔ فاصله یا علامت توان پایانی قرار گیرند. برای مثال:

: foo.c |> ^c CC %f^ gcc --coverage %f -o %o |> foo | foo.gcno
: bar.c |> ^c^ gcc --coverage %f -o %o |> bar | bar.gcno

در مورد foo.c، دستور نیازمند فضاهای نام (namespaces) (یا suid) است و «CC foo.c» را نمایش می‌دهد. در مورد bar.c، دستور نیازمند فضاهای نام (یا suid) است و رشتهٔ «gcc --coverage bar.c -o bar» نمایش داده می‌شود. نویسه‌های پرچم پشتیبانی‌شده عبارت‌اند از:

%-flags

درون یک رشتهٔ دستور یا رشتهٔ خروجی، می‌توان از پرچم‌های % زیر برای جایگزینی مقادیر از ورودی‌ها یا خروجی‌ها استفاده کرد. به‌طور کلی، پرچم‌های % به تمام نام‌های فایل در یک فهرست گسترش می‌یابند. برای مثال، %o به تمام فایل‌های خروجی بسط داده می‌شود. برای ارجاع به یک فایل تکی، می‌توانید از %1o، %2o و غیره برای اشاره به اولین، دومین (و به همین ترتیب) نام فایل در فهرست استفاده کنید.

var = value

var := value

مقدار متغیر-$ با نام "var" را برابر با مقدار سمت راست قرار می‌دهد. هر دو شکل یکسان هستند و برای پشتیبانی آسان‌تر از تبدیل Makefileهای قدیمی مجاز شمرده شده‌اند. بعداً می‌توان با استفاده از "$(var)" به متغیر-$ با نام "var" ارجاع داد. متغیرهای ارجاع‌شده در اینجا همواره بلافاصله بسط می‌یابند. بنابراین، مقداردهی متغیر به‌گونه‌ای که شامل یک پرچم-% باشد بی‌معنی است، زیرا یک پرچم-% تنها در یک قاعده-: معتبر است. نحو $(var_%e) در یک قاعده-: مجاز است. ارجاع‌های متغیر تودرتو نمی‌شوند، بنابراین عبارتی مانند $(var1_$(var2)) بی‌معنی است. همچنین نمی‌توانید تعاریف متغیر را در خط فرمان یا از طریق محیط منتقل کنید. هرگونه ارجاع به متغیری که مقدار آن تعیین نشده باشد، یک رشته خالی بازمی‌گرداند.

CFLAGS = -Dfoo
: bar.c |> cc $(CFLAGS) $(other) -o %o -c %f |> %B.o

در زمان اجرا، دستور "cc -Dfoo -o bar.o -c bar.c"; را تولید خواهد کرد.

هر متغیر-$ که با رشته "CONFIG_" آغاز شود، به‌طور خودکار به متغیر-@ با همان نام منهای پیشوند "CONFIG_" تبدیل می‌شود. به عبارت دیگر، $(CONFIG_FOO) و @(FOO) قابل تعویض با یکدیگرند. تلاش برای انتساب مقدار به یک متغیر CONFIG_ در یک Tupfile منجر به بروز خطا می‌شود، زیرا این متغیرها تنها در فایل tup.config قابل تنظیم هستند.

توجه داشته باشید که ممکن است هنگام مقداردهی متغیرها با نحوی مواجه شوید که از بک‌تیک‌ها استفاده می‌کند، مانند:

CFLAGS += `pkg-config fuse3 --cflags`

ابزار tup هیچ‌گونه پردازش ویژه‌ای روی بک‌تیک‌ها انجام نمی‌دهد، بنابراین در این مثال هنگام مقداردهی متغیر، دستور pkg-config واقعاً اجرا نمی‌شود. در عوض، این عبارت عیناً به هر مکانی که از آن استفاده کند منتقل می‌شود. از این رو اگر دستوری بعداً به $(CFLAGS) ارجاع دهد، شامل رشته `pkg-config fuse3 --cflags` خواهد بود و بنابراین توسط پوسته (shell) تجزیه خواهد شد.

var += value

مقدار "value" را به انتهای مقدار فعلی "var" الحاق می‌کند. اگر "var" مقداردهی نشده باشد، این عمل معادل یک عبارت معمولی '=' است. اگر "var" از قبل مقداری داشته باشد، پیش از الحاق مقدار جدید، یک فاصله به متغیر-$ اضافه می‌شود.

$(TUP_CWD)

[lua] tup.getcwd()

متغیر-$ ویژه TUP_CWD همواره روی مسیر نسبی نسبت به Tupfile که اکنون در حال تجزیه است، تنظیم می‌شود. مقدار آن هنگام include کردن فایلی در یک دایرکتوری دیگر می‌تواند تغییر کند. برای مثال، اگر از "include ../foo.tup" استفاده کنید، آنگاه TUP_CWD هنگام تجزیه foo.tup روی ".." تنظیم خواهد شد. این قابلیت به foo.tup اجازه می‌دهد پرچم‌هایی مانند "CFLAGS += -I$(TUP_CWD)" را مشخص کند و CFLAGS صرف‌نظر از اینکه به صورت "../foo.tup" یا "../../foo.tup" یا "subdir/foo.tup" گنجانده شده باشد، همواره شامل دایرکتوری -I که foo.tup در آن قرار دارد خواهد بود. برای یافتن جایگزینی برای $(TUP_CWD) هنگام ارجاع به فایل‌ها، بخش مربوط به متغیرهای-& در زیر را ببینید.

$(TUP_VARIANTDIR)

[lua] tup.getvariantdir()

مشابه $(TUP_CWD)، متغیر $(TUP_VARIANTDIR) نیز روی مسیر نسبی نسبت به Tupfile در حال تجزیه تنظیم می‌شود، اما به دایرکتوری متناظر در variant اشاره می‌کند. به‌عنوان مثالی از کاربرد این قابلیت، فرض کنید فرآیند ساخت شما هدرهای مشترک را در دایرکتوری با نام "include/" تولید می‌کند. یک فایل Tuprules.tup در سطح همان دایرکتوری می‌تواند -I$(TUP_VARIANTDIR) را به یک متغیر پرچم‌های کامپایلر اضافه کند. در صورت استفاده از یک variant، این مقدار به مسیری مانند "../build/path/to/include" ارزیابی می‌شود که در آن "build" نام دایرکتوری variant است. اگر از variantها استفاده نشود، TUP_VARIANTDIR معادل TUP_CWD خواهد بود.

$(TUP_VARIANT_OUTPUTDIR)

[lua] tup.getvariantoutputdir()

متغیر $(TUP_VARIANT_OUTPUTDIR) همواره به دایرکتوری خروجی متناظر با variantای که اکنون در حال تجزیه است اشاره می‌کند. برخلاف $(TUP_VARIANTDIR)، هنگام گنجاندن فایل دیگری مانند Tuprules.tup یا سایر فایل‌های جزئی *.tup تغییر نمی‌کند. بدون استفاده از variantها، این مقدار همواره برای اشاره به دایرکتوری جاری به رشته "." ارزیابی می‌شود.

هنوز هیچ متغیر-$ ویژه دیگری وجود ندارد، اما برای رعایت جانب احتیاط باید فرض کنید که تمام متغیرهای با نام *TUP_ رزرو شده‌اند.

&var = file

&var := file

&var += file

متغیر-& را برای ارجاع به فایل یا دایرکتوری مشخص‌شده تنظیم می‌کند. این فایل باید یک فایل معمولی باشد، نه یک فایل تولیدشده (یک خروجی از یک قاعده-:). متغیرهای-& به شیوه‌ای مشابه $(TUP_CWD) برای ارجاع به فایل‌ها استفاده می‌شوند، با این تفاوت که به جای ذخیره مسیر نسبی به فایل، متغیرهای-& شناسه داخلی فایل در tup را ذخیره می‌کنند. این بدان معناست که مسیر نسبی به فایل زمانی تعیین می‌شود که متغیر-& به کار می‌رود، نه در زمان انتساب متغیر همانند آنچه در $(TUP_CWD) رخ می‌دهد. متغیرهای-& تنها در مکان‌های زیر قابل استفاده هستند: ورودی‌های قاعده-:، ورودی‌های فقط-ترتیبی (order-only) قاعده-:، دستورهای قاعده-:، خطوط include و خطوط run-script؛ و بعداً می‌توان با استفاده از "&(var)" به آن‌ها ارجاع داد.

# Tuprules.tup
&libdir = src/lib
!cc = |> cc -I&(libdir) -c %f -o %o |> %B.o
# src/lib/Tupfile
: foreach *.c |> !cc |>
: *.o |> ar crs %o %f |> libstuff.a
# src/lib/test/Tupfile
: test_stuff.c |> !cc |>
: test_stuff.o &(libdir)/libstuff.a |> cc -o %o %f |> test_stuff
# src/Tupfile
: main.c |> !cc |> main.o
: main.o &(libdir)/libstuff.a |> cc -o %o %f |> main_app

دستورهای build.sh زیر را تولید خواهد کرد (از طریق "tup generate build.sh"):

cd src/lib
cc -I. -c lib1.c -o lib1.o
cc -I. -c lib2.c -o lib2.o
ar crs libstuff.a lib1.o lib2.o
cd test
cc -I.. -c test_stuff.c -o test_stuff.o
cc -o test_stuff test_stuff.o ../libstuff.a
cd ../..
cc -Ilib -c main.c -o main.o
cc -o main_app main.o lib/libstuff.a

ifeq (lval,rval)

پارامترهای 'lval' و 'rval' را ارزیابی می‌کند (یعنی: تمام متغیرهای-$ و متغیرهای-@ را جایگزین می‌کند) و یک مقایسه رشته‌ای انجام می‌دهد تا ببیند آیا با یکدیگر مطابقت دارند یا خیر. در این صورت، تمام خطوط بین 'ifeq' و عبارت 'endif' پس از آن پردازش می‌شوند؛ در غیر این صورت نادیده گرفته می‌شوند. توجه داشته باشید که هیچ فاصله خالی (whitespace) از مقادیر حذف نمی‌شود - تمام متن میان '(' و ',' تشکیل‌دهنده 'lval' است و تمام متن میان ',' و ')' تشکیل‌دهنده 'rval' است. این بدان معناست که ifeq (foo, foo) نادرست (false) است، در حالی که ifeq (foo,foo) درست (true) می‌باشد. این رفتار جهت سازگاری با دستورات شرطی if در Makefile است.

ifeq (@(FOO),y)
CFLAGS += -DFOO
else
CFLAGS += -g
endif

ifneq (lval,rval)

مشابه 'ifeq'، اما با منطق معکوس.

ifdef VARIABLE

بررسی می‌کند که آیا متغیر-@ با نام VARIABLE اصلاً در tup.config تعریف شده است یا خیر. در این صورت، تمام خطوط بین 'ifdef' و عبارت 'endif' پس از آن پردازش می‌شوند؛ در غیر این صورت نادیده گرفته می‌شوند. برای مثال، فرض کنید tup.config شامل مورد زیر باشد:

CONFIG_FOO=n

در این حالت 'ifdef FOO' به مقدار درست (true) ارزیابی خواهد شد. اگر tup.config وجود نداشته باشد، یا CONFIG_FOO را به هیچ شکلی تنظیم نکرده باشد، آنگاه 'ifdef FOO' نادرست (false) خواهد بود.

ifndef VARIABLE

مشابه 'ifdef'، اما با منطق معکوس.

else

وضعیت درستی/نادرستی (true/false) عبارت شرطی if قبلی را معکوس می‌کند.

endif

به عبارت شرطی قبلی ifeq/ifdef/ifndef پایان می‌دهد. توجه داشته باشید که تنها تا ۸ سطح تودرتویی برای عبارات if پشتیبانی می‌شود.

error [message]

باعث توقف تجزیه در tup و شکست فرآیند شده و message را به عنوان توضیح به کاربر نمایش می‌دهد.

!macro = [inputs] | [order-only inputs] |> command |> [outputs]

ماکروی-! را روی رشته دستور داده‌شده تنظیم می‌کند. این نحو بسیار مشابه با قاعده-: است، چرا که یک ماکروی-! در اصل ماکرویی برای آن قواعد است. ماکروی-! تا زمانی که در رشته دستور یک قاعده-: استفاده نشود بسط داده نمی‌شود. بنابراین، کاربرد اصلی ماکروی-! داشتن مکانی برای ذخیره رشته‌های دستور حاوی پرچم‌های-% است که می‌توانند مجدداً استفاده شوند. برای مثال، می‌توانیم یک ماکروی !cc در فایل ریشه Tuprules.tup به این شکل داشته باشیم:

!cc = |> ^ CC %f^ gcc -c %f -o %o |>

سپس یک Tupfile می‌تواند به شکل زیر عمل کند:

include_rules
: foreach *.c |> !cc |> %B.o

شما مایل خواهید بود که پارامتر خروجی را یا در ماکروی-! یا در قاعده-: که از آن استفاده می‌کند مشخص کنید، نه در هر دو. اگر هرگونه ورودی در ماکروی-! تعیین کنید، معمولاً ورودی‌های فقط-ترتیبی (order-only) خواهند بود. برای مثال، اگر قاعده !cc دارید که در آن از کامپایلری استفاده می‌کنید که توسط tup تولید شده است، می‌توانید فایل کامپایلر را در فهرست order-only ماکروی-! قید کنید. فایل کامپایلر سپس به یک وابستگی ورودی برای هر قاعده-: که از آن ماکرو استفاده می‌کند تبدیل خواهد شد.

include file

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

include_rules

فایل‌های Tuprules.tup را در امتداد سلسله‌مراتب دایرکتوری به سمت بالا می‌خواند. نخستین فایل Tuprules.tup در بالاترین سطح ساختار سلسله‌مراتبی tup خوانده می‌شود، سپس زیردایرکتوری بعدی و به همین ترتیب تا فایل Tuprules.tup در دایرکتوری جاری ادامه می‌یابد. بدین ترتیب، فایل ریشه Tuprules.tup می‌تواند تنظیمات متغیرهای عمومی را مشخص کند و زیردایرکتوری‌های بعدی می‌توانند آن‌ها را با تنظیمات خاص‌تر بازنویسی (override) نمایند. عموماً include_rules را به عنوان نخستین خط در Tupfile قرار می‌دهید. این نام تا حدودی نام‌گذاری نادقیق است، زیرا شما معمولاً از Tuprules.tup برای تعریف متغیرها استفاده می‌کنید تا قواعد-:.

run ./script args

یک اسکریپت خارجی را با آرگومان‌های داده‌شده برای تولید قواعد-: اجرا می‌کند. این یک ویژگی پیشرفته است و زمانی می‌تواند استفاده شود که نحو استاندارد Tupfile برای برنامه‌ای پیچیده بیش از حد ساده باشد. انتظار می‌رود این اسکریپت قواعد-: را در خروجی استاندارد (stdout) بنویسد. هیچ دستور دیگر Tupfile مجاز نیست - برای مثال، اسکریپت نمی‌تواند متغیرهای-$ یا ماکروهای-! ایجاد کند، اما می‌تواند قواعدی-: تولید کند که از این ویژگی‌ها بهره می‌برند. به عنوان یک مثال ساده، در نظر بگیرید اگر فرمانی باید ۵ بار اجرا شود، اما هیچ فایل ورودی وجود ندارد تا بتوان از کلیدواژه foreach در tup استفاده کرد. یک اسکریپت خارجی به نام 'build.sh' می‌تواند به شکل زیر نوشته شود:

#! /bin/sh -e
for i in `seq 1 5`; do
	echo ": |> echo $i > %o |> $i.txt"
done

سپس یک Tupfile می‌تواند برای دریافت این قواعد استفاده شود:

run ./build.sh

سپس tup با این حالت طوری رفتار می‌کند که گویی یک Tupfile با ۵ خط به این صورت نوشته شده است:

: |> echo 1 > %o |> 1.txt
: |> echo 2 > %o |> 2.txt
: |> echo 3 > %o |> 3.txt
: |> echo 4 > %o |> 4.txt
: |> echo 5 > %o |> 5.txt

از آنجا که مرحله تجزیه Tupfile برای ردیابی وابستگی‌ها پایش می‌شود، دسترسی این اسکریپت به هر فایلی درون سلسله‌مراتب tup باعث تجزیه مجدد Tupfile خواهد شد. با این حال محدودیت‌هایی وجود دارد. نخست اینکه فراخوانی ()readdir مجهز شده است تا فهرست فایل‌هایی را بازگرداند که در زمان آغاز اجرای اسکریپتِ run در دسترس بوده‌اند. این بدان معناست که فایل‌هایی که با دستور 'ls' در خط فرمان می‌بینید ممکن است با فایل‌هایی که اسکریپت شما هنگام تجزیه شدن مشاهده می‌کند متفاوت باشند. ابزار tup اساساً وانمود می‌کند که فایل‌های تولیدشده وجود ندارند تا زمانی که یک قاعده-: را تجزیه کند که آن فایل را به عنوان خروجی فهرست کرده باشد. توجه داشته باشید که هر قاعده-: اجراشده توسط خود اسکریپتِ run تا زمانی که اسکریپت با موفقیت اجرا نشود، تجزیه نخواهد شد. دوم اینکه به دلیل برخی محدودیت‌های ساختاری در tup، اسکریپت نمی‌تواند روی هیچ دایرکتوری به جز دایرکتوری Tupfile فراخوانی ()readdir انجام دهد. به عبارت دیگر، یک اسکریپت می‌تواند عبارت 'for i in *.c' را انجام دهد، اما نمی‌تواند 'for i in sub/*.c' را اجرا کند. پرچم '--debug-run' می‌تواند به 'tup' ارسال شود تا فهرست قواعدی-: که tup از اسکریپت دریافت می‌کند را نمایش دهد. با توجه به ابزارگذاری ()readdir، ممکن است این فهرست با خروجی اسکریپت در زمان اجرای دستی آن از خط فرمان تفاوت داشته باشد.

preload directory

به‌طور پیش‌فرض، یک اسکریپتِ run تنها می‌تواند از ()readdir (یعنی: استفاده از نویسه عام / wildcard) روی دایرکتوری جاری استفاده کند. برای تعیین فهرستی از سایر دایرکتوری‌های مجاز برای نویسه‌های عام، از کلیدواژه preload استفاده کنید. برای مثال، اگر یک اسکریپت run نیاز به بررسی *.c و src/*.c داشته باشد، دایرکتوری src باید از قبل بارگذاری (preload) شود:

preload src
run ./build.sh *.c src/*.c

export VARIABLE

دستور export متغیر محیطی VARIABLE را به فهرست صادرات (export) برای قواعد-: و اسکریپت‌های run آینده اضافه می‌کند. مقدار متغیر از محیط tup می‌آید، نه از خود Tupfile. عموماً این بدان معناست که اگر مایلید مقدار مورداستفاده در دستورها و اسکریپت‌ها را تغییر دهید، باید متغیر را در پوسته (shell) خود تنظیم کنید. به‌طور پیش‌فرض تنها PATH صادر می‌شود. ویندوز علاوه بر این چندین متغیر مناسب برای ساخت با مجموعه کامپایلر Visual Studio را صادر می‌کند. ابزار tup متغیرهای محیطی صادرشده را بررسی می‌کند تا ببیند آیا مقادیر آن‌ها بین به‌روزرسانی‌ها تغییر کرده است یا خیر، و هر دستوری که از آن متغیرهای محیطی استفاده می‌کند را مجدداً اجرا می‌نماید. توجه داشته باشید این بدان معناست که اگر PATH تغییر کند، تمام دستورها مجدداً اجرا خواهند شد. برای مثال:

: |> command1 ... |>
export FOO
: |> command2 ... |>

ابزار tup مقدار فعلی FOO را ذخیره کرده و هنگام اجرای command2 آن را به محیط منتقل می‌کند. اگر FOO هنگام به‌روزرسانی بعدی مقدار متفاوتی داشته باشد، آنگاه command2 مجدداً با مقدار جدید در محیط اجرا خواهد شد. در این مثال، command1 متغیر FOO را در محیط خود نخواهد داشت و با تغییر مقدار آن مجدداً اجرا نخواهد شد.

توجه داشته باشید که FOO در بالا به محیط منتقل می‌شود؛ به عنوان یک متغیر داخلی در tup در دسترس قرار نمی‌گیرد. بنابراین، با در نظر گرفتن مورد زیر:

export FOO
: |> echo myFOO=$(FOO) envFOO=${FOO} > %o |> foo.txt

هنگامی که به صورت "$ FOO=silly tup" اجرا شود، محتوای فایل foo.txt برابر با "myFOO= envFOO=silly" خواهد بود. اگر دستور "export FOO" از Tupfile حذف می‌شد، محتوای فایل برابر با "myFOO= envFOO=" می‌بود، زیرا tup متغیرهای محیطی را منتشر نمی‌کند مگر اینکه صراحتاً صادر (export) شده باشند. این کار به حفظ ساخت‌های تکرارپذیر و قطعی (deterministic) کمک می‌کند.

اگر مایلید به جای دریافت مقدار از محیط، متغیری را با یک مقدار معین صادر کنید، می‌توانید این کار را در پوسته خود به جای tup انجام دهید. برای مثال در Linux می‌توانید انجام دهید:

: |> FOO=value command ... |>

این کاربرد وابستگی به متغیر محیطی FOO ایجاد نمی‌کند، زیرا از طریق Tupfile کنترل می‌شود..TP import VARIABLE[=default] دستور import متغیری را درون Tupfile تنظیم می‌کند که مقدار متغیر محیطی را در بر دارد. اگر متغیر محیطی مقداردهی نشده باشد، در صورت تعیین، مقدار پیش‌فرض به جای آن استفاده می‌شود. این کار وابستگی‌ای از متغیر محیطی به Tupfile ایجاد می‌کند، به طوری که در صورت تغییر متغیر محیطی، Tupfile مجدداً تجزیه می‌شود. برای مثال:

import CC=gcc
: foreach *.c |> $(CC) -c %f -o %o |> %B.o

این دستور تمام فایل‌های ‎.c را با کامپایلر تعریف‌شده در متغیر محیطی CC کامپایل می‌کند. اگر CC در محیط تنظیم نشده باشد، از gcc به عنوان پیش‌فرض استفاده خواهد شد. در ساخت بعدی، اجرای دستور 'CC=clang tup' باعث تجزیهٔ مجدد این Tupfile و بازسازی تمام فایل‌های ‎.c با clang خواهد شد (زیرا خطوط فرمان تغییر کرده‌اند).

برخلاف 'export'، دستور import متغیرها را به محیط زیرپردازه ارسال نمی‌کند. بنابراین در مثال قبلی، متغیر محیطی CC در زیرپردازه تنظیم نمی‌شود، مگر اینکه 'export CC' نیز در Tupfile قرار داده شده باشد.

.gitignore

به tup اعلام می‌کند که به طور خودکار یک فایل .gitignore در دایرکتوری جاری بسازد که حاوی فهرستی از فایل‌های خروجی تولیدشده توسط tup است. در صورت استفاده از git، این قابلیت می‌تواند مفید باشد؛ زیرا مجموعه فایل‌های تولیدشده توسط tup دقیقاً منطبق بر فایل‌هایی است که می‌خواهید git نادیده بگیرد. اگر از فایل‌های Tuprules.tup استفاده می‌کنید، ممکن است ترجیح دهید تنها .gitignore را در سطح بالاترین Tuprules.tup مشخص کنید و سپس در سایر Tupfileها از include_rules برای اعمال تعریف .gitignore استفاده نمایید. با این روش نیازی به مدیریت دستی فایل‌های .gitignore نخواهید داشت. توجه داشته باشید که ممکن است بخواهید فایل‌های دیگری را که توسط tup ساخته نشده‌اند نیز نادیده بگیرید، مانند فایل‌های موقتی که توسط ویرایشگر شما ایجاد می‌شوند. در این حالت می‌توانید با استفاده از دستوری مانند 'git config --global core.excludesfile ~/.gitignore' یک فایل gitignore سراسری راه‌اندازی کنید و سپس ~/.gitignore را با فهرست شخصی خود تنظیم نمایید. برای سایر موارد، همچنین می‌توانید به سادگی هر قاعدهٔ نادیده‌گیری دلخواهی را در بالای خط "##### TUP GITIGNORE #####" اضافه کنید.

#

در ابتدای یک خط، نویسهٔ '#' نشان‌دهندهٔ توضیح (کامنت) است. خط توضیح توسط تجزیه‌کننده نادیده گرفته می‌شود. توضیح می‌تواند فاصله‌های خالی ابتدایی داشته باشد که آن‌ها نیز نادیده گرفته می‌شوند. اگر قبل از نویسهٔ '#' هر نویسهٔ غیرفاصله‌ای وجود داشته باشد، خط به عنوان توضیح در نظر گرفته نمی‌شود. این همچنین بدین معنی است که اگر خط قبلی با '\' (شکستن خط) خاتمه یافته باشد، '#' به عنوان یک نماد معمولی تفسیر می‌شود.