makepp_build_cache_control - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

makepp_build_cache -- Як налаштувати та використовувати кеші збірки

ОПИС

C: чистий,
створювати, M: makepp_build_cache_control,
mppbcc, S: показувати,
статистика

A будувати cache це каталог, що містить копії попередніх цілей, які вже makepp
побудований. Коли makepp просять створити нову ціль, він бачить, чи вже створив її
десь в іншому місці за тих самих умов, і якщо так, то просто посилає або копіює його замість
перебудовуючи його.

Кеш збірки може бути корисним у таких випадках:

· Ви працюєте над програмою і компілюєте її оптимізовано. Тоді ви виявите помилку,
і перекомпілюйте все це в режимі налагодження. Ви знайшли помилку і тепер хочете це зробити
перекомпілюйте його в оптимізованому режимі. Більшість файлів будуть ідентичними. Якщо ви використовували a
побудуйте кеш у всіх ваших компіляціях, makepp просто витягне незмінні файли
з кешу збірки, а не перекомпілювати їх.

Подібна ситуація, якщо ви зазвичай працюєте над однією архітектурою, але ненадовго перемикаєтеся на неї
іншу архітектуру, а потім ви перейдете назад. Якщо старі файли все ще знаходяться в
побудувати кеш, makepp не доведеться нічого перекомпілювати.

· Ви витягли кілька копій певної програми зі свого контролю версій
системи та внесли різні зміни в кожну ієрархію каталогів. (Наприклад, ви
вирішення різних помилок в різних ієрархіях каталогів.) Більшість файлів буде
ідентичні в двох ієрархіях каталогів. Якщо ви збираєте обидва за допомогою кешу збірки, то
build у другій ієрархії каталогів зможе просто скопіювати файли з
створювати кеш, а не перекомпілювати однакові файли.

· У вас є кілька розробників, які працюють над одним набором джерел. Кожен розробник є
внесення змін, але більшість файлів ідентичні між розробниками. Якщо всі
розробники спільно використовують кеш збірки, то якщо збірка одного розробника компілює файл, будь-який
збірка іншого розробника, яка має скомпілювати ідентичний файл (з тим самим
включає, тощо) може просто скопіювати кешований файл замість повторного запуску компіляції.

Кеш збірки може допомогти, якщо все з наступного вірно:

· У вас багато місця на диску. Зазвичай makepp кешує багато копій
кожен файл, який змінюється, тому що він не знає, які саме будуть використовуватися.
Ви можете вимкнути кеш збірки для певних файлів, але якщо кеш збірки збирається
бути корисним взагалі, ймовірно, у ньому буде багато файлів.

· Створення файлів займає значно більше часу, ніж копіювання. Якщо кеш збірки знаходиться на
У тій же файловій системі makepp намагатиметься використовувати жорсткі посилання, а не копіювати файл.
Makepp повинен зв’язати або скопіювати файл у кеш, коли файл буде створено, а потім його
має зв’язати або скопіювати файл із кешу, коли це знову знадобиться. Крім того,
є невеликі накладні витрати на перевірку того, чи дійсно потрібний файл знаходиться
кеш збірки та копіювання інформації про збірку про файл, а також файл
себе.

Наприклад, ви можете виявити, що використання кешу збірки не варто того, щоб його компілювати
невеликі модулі. Майже напевно не варто, щоб команди створювали статику
бібліотека (архівний файл, libxyz.a), за винятком випадків, коли ви використовуєте посилання для економії місця на диску.

· Є велика ймовірність, що одні файли знадобляться знову в іншому
компіляція. Якщо ви збираєте програмне забезпечення лише один раз, можна створити кеш
тільки уповільнює справу.

Використання кешу збірки вимагає невеликих налаштувань та робіт з обслуговування. Будь ласка, не
Спробуйте використовувати кеш збірки, доки не зрозумієте, як вони працюють, як їх створити та як
не дозволяйте їм постійно зростати і не поглинати весь доступний дисковий простір на вашому диску
системи.

Як a будувати cache працює
Якщо ви ввімкнете кеш збірки, кожен раз, коли файл збирається, makepp зберігає копію в файлі a
побудувати кеш. Ім’я файлу – це ключ, який є хешем контрольних сум усіх
входи, команда збірки та архітектура. Наступного разу makepp захоче перебудувати
файл, він перевірить, чи є файл із такими самими контрольними сумами вже в кеші збірки.
Якщо так, файл копіюється з кешу збірки.

Для ефективності, якщо кеш збірки розташований в тій же файловій системі, що й збірка, makepp
фактично не копіює файл; замість цього він створить жорстке посилання. Це швидше і
не використовує зайвий дисковий простір. Аналогічно, коли makepp хоче витягти файл
кеш збірки, він використовуватиме жорстке посилання, якщо це можливо, або скопіювати його, якщо необхідно.

ПОПЕРЕДЖЕННЯ: Макепп ніколи видаляє файли з кешу збірки, якщо про це не запитають явно.
Це означає, що ваші кеші збірок продовжуватимуть безмежно зростати, якщо ви не очистите
їх періодично підвищувати (докладніше див. нижче).

Будувати кеш-пам'ять та сховища

Створення кешів і репозиторіїв (див. makepp_repositories) може вирішити подібні проблеми. Для
в деяких ситуаціях сховище є більш доречним, а в інших — кеш збірки
необхідності.

Ви також можете комбінувати обидва. Якщо у вас величезна структура каталогів з великою кількістю
джерела, копії яких ви не хочете, щоб кожен розробник мав, тоді ви можете надати їх
як сховище. Зроблені файли з різними параметрами налагодження тощо можуть бути
керується більш гнучко за допомогою кешу збірки.

Основні відмінності між кешом збірки та репозиторієм:

· Кеш збірки може зберігати лише файли, створені процедурою збірки. Репозиторій може
також мають оригінальні вихідні файли.

· Файли в репозиторії повинні НЕ змінюватися під час побудови. Кеш збірки
не має такого обмеження.

· Файли в сховищі повинні знаходитися в тому самому відносному положенні, що й файли в
каталог збірки. Наприклад, якщо makepp потрібен файл subdir1/subdir2/xyz.abc, то це
тільки дивиться кореневий_репозиторій/підкаталог1/підкаталог2/xyz.abc. Файли в кеші збірки мають
втратили всю інформацію про ієрархію каталогів, і їх шукають лише на основі введених даних
і команди, які були необхідні для їх створення.

· Файли в сховищі м'яко зв'язуються з новими місцями в збірці
каталогів. Файли в кеші збірки копіюються або жорстко пов’язуються в їх новий
місця розташування. Якщо копія потрібна, репозиторій, безумовно, буде швидше.

· Створення кешей коштує трохи часу для розміщення в них файлів. Репозиторію немає
будь-які додаткові витрати (для поточного виконання, тобто, звичайно, були витрати на створення
це заздалегідь), але часто вимагає дещо більшого попереднього планування.

Загалом, репозиторій є кориснішим, якщо у вас є єдина центральна збірка, яку ви хочете
всі розробники, з яких можна взяти файли. Кеш збірки — це те, що вам потрібно, якщо у вас є файл
децентралізована система, де один розробник повинен запозичувати скомпільовані файли в будь-якого іншого
розробника.

І кеші збірки, і репозиторії можуть допомогти зі створенням варіантів. Наприклад, якщо ви хочете
щоб зібрати всі ваші джерела оптимізовано, потім знову з налагодженням, потім знову оптимізовано,
Ви можете уникнути повторної компіляції всіх оптимізованих файлів, використовуючи репозиторій або a
побудувати кеш. Щоб зробити це зі сховищем, ви повинні подумати наперед і чітко сказати
makepp використовувати репозиторій для компіляції налагодження, інакше він знищить ваші
початкова оптимізована компіляція. За допомогою кешу збірки makepp продовжує і видаляє файли
початкова оптимізована компіляція, але її можна швидко відновити.

Будувати cache групування
Група – це нещільне з’єднання кешів збірки. Він вільний у тому сенсі, що makepp не робить
впоратися з ним, щоб не сповільнювати керування кешом збірки. Щоб отримати від цього користь
необхідно використовувати автономну утиліту. Зокрема, команда «очистити» також виконує
реплікація. Якщо ви вкажете нереалістичний критерій очищення, наприклад "--mtime=+1000", ні
відбувається очищення, тільки реплікація.

Групування дозволяє ділитися файлами з більшою кількістю людей, особливо якщо у вас є кеш збірки
на дисках розробників, щоб скористатися жорстким зв’язуванням, що заощаджує час подання та
дискового простору. Однак лише жорстке підключення обмежено перевагами для кожного диска.

З групуванням файл буде реплікований через деякий час після того, як makepp передасть його до
побудувати кеш. Це означає, що файл буде створено лише один раз для всіх дисків разом.

На файлових системах, які дозволяють жорстке посилання на символічні посилання, що здається обмеженим
Linux і Solaris – файл додатково буде фізично присутній лише на одному диску.
Крім того, він залишається на кожному диску, на якому він був створений перед реплікацією, але тільки як
поки він використовується на цих дисках. У цьому випадку із символічними посиланнями ви можете вибрати один або
більше файлових систем, на яких ви віддаєте перевагу, щоб ваші файли були фізично. Усвідомте це
успішно створені файли можуть стати недоступними, якщо диск, на якому вони знаходяться, фізично зникне
офлайн. Перебудова виправить це, і вплив можна зменшити, розповсюдивши
файли на кількох бажаних дисках.

Реплікація має кілька цікавих застосувань:

NFS (можливо також з копіюванням)
У вас є центральний сервер NFS, який надає бажаний кеш збірки. Кожна машина
а диск розробника має локальний кеш збірки для швидкого подання. Ви або сідайте назад
всі диски розробника на сервер NFS і виконайте реплікацію та очищення
централізовано, або ви реплікуєте локально на кожній клієнтській машині NFS, обробляючи лише частину
видимої там групи.

Небезпечний диск (можливо також з копіюванням)
Якщо ви компілюєте на диску RAM (сподіваємося, редагуєте свої джерела в репозиторії на безпечному
disk), ви можете вибрати безпечні диски. Тоді буде реплікація
перенести файли на безпечні диски, де вони виживають після перезавантаження. Після кожного перезавантаження
вам доведеться повторно створити кеш збірки RAM-диска та додати його до групи (що буде
дати попередження, нешкідливе в даному випадку, тому що інші учасники групи все ще пам'ятають
це).

Повний диск (жорстке посилання лише на символічні посилання)
Якщо один із ваших дисків, як відомо, заповнений, ви можете створити кеш збірки на всіх дисках
надавати перевагу іншим дискам. Таким чином, реплікація перенесе файли з файлу
повний диск, випадковим чином на будь-який з інших.

Як до використання a будувати cache
Як до сказати makepp до використання будувати cache

Після створення кешу збірки він доступний для makepp. Є декілька
параметри, які можна вказати під час створення; див. «Як керувати кешем збірки» для отримання детальнішої інформації.

Кеш збірки вказується за допомогою параметра командного рядка --build-cache, за допомогою параметра
Оператор build_cache у файлі make-файлу або з модифікатором правила :build_cache.

Найкорисніші способи, які я знайшов для роботи з кешами збірки:

· Встановіть шлях кешу збірки у змінній середовища MAKEPPFLAGS, як це (по-перше
варіант для Korn Shell або bash, другий для csh):

експорт MAKEPPFLAGS=--build-cache=/path/to/build/cache
setenv MAKEPPFLAGS --build-cache=/шлях/до/збірки/кешу

Тепер кожна запущена вами збірка завжди використовуватиме цей кеш збірки, і вам це не потрібно
змінити щось інше.

· Вкажіть кеш збірки у ваших make-файлах за допомогою рядка, подібного до цього:

BUILD_CACHE := /шлях/до/кеш_побудови
build_cache $(BUILD_CACHE)

Ви повинні помістити це у всі make-файли, які використовують кеш збірки (або в загальний вкл
файл, який використовують усі make-файли). Або покладіть це у свій RootMakeppфайл:

BUILD_CACHE := /шлях/до/кеш_побудови
глобальний build_cache $(BUILD_CACHE)

На багатокористувацькій машині ви можете налаштувати один кеш збірки для кожного домашнього диска
перевага посилань. Можливо, вам буде зручніше використовувати такий оператор:

build_cache $(find_upwards our_build_cache)

який шукає вгору від поточного каталогу в поточній файловій системі до його
знаходить каталог з ім our_build_cache. Це може бути однакове твердження для всіх
користувачів і все одно окремо вказують на кеш на їхньому диску.

Solaris 10 може зробити деяке фантастичне перемонтування домашніх каталогів. Ваш дім буде
мабуть, є окремою точкою монтування, що називається / home /$LOGNAME, коли насправді він включений
один з /export/home* диски поряд з дисками інших користувачів. Тому що це не так
дійсно окрема файлова система, посилання все ще працюють. Але ви не можете шукати вгору.
Замість цього ви можете зробити:

BUILD_CACHE := ${makeperl }

Будувати кеш-пам'ять та підпису

Makepp шукає файли в кеші збірки відповідно до їхніх підписів. Якщо ви використовуєте
метод підпису за замовчуванням (дата + розмір файлу), makepp витягуватиме лише файли з файлу
побудувати кеш, якщо дата файлу вхідних файлів ідентична. Залежно від вашої конструкції
працює, дати файлу можуть ніколи не бути однаковими. Наприклад, якщо ви перевіряєте файли в
дві різні ієрархії каталогів, датами файлів, ймовірно, будуть час, який ви перевірили
файли, а не час, коли файли були перевірені (звісно, ​​залежно від вашого
програмне забезпечення для контролю версій).

Напевно, вам потрібно витягнути файли з кешу збірки, якщо файл зміст він має
ідентичні, незалежно від дати. Якщо це так, ви повинні використовувати якийсь
підпис на основі вмісту. Makepp робить це за замовчуванням для компіляцій C і C++, але це
використовує дати файлів для будь-яких інших типів файлів (наприклад, об’єктних файлів або будь-яких інших файлів у
процес збірки спеціально не розпізнається як вихідний файл C або включаючий файл). Якщо хочеш
інші типи файлів для роботи з кешем збірки (тобто, якщо ви хочете, щоб він працював з
будь-що інше, ніж команди компіляції C/C++), тоді ви можете ввести такий оператор
десь у верхній частині вашого make-файлу:

підпис md5

щоб змусити makepp використовувати підписи на основі вмісту файлів, а не їх дати.

Як НЕ до cache певний файли

Можливо, є певні файли, які, як ви знаєте, ніколи не захочете кешувати. Наприклад, якщо
Ви вставляєте штамп дати у файл, ви знаєте, що цього не зробите ні за яких обставин
хочете отримати попередню копію файлу з кешу збірки, оскільки штамп дати
інакший. У цьому випадку копіювати його в файл буде просто марною тратою часу та дискового простору
побудувати кеш.

Або ви можете подумати, що малоймовірно, що вам захочеться кешувати кінцевий виконуваний файл.
Можливо, ви захочете кешувати окремі об’єкти або спільні об’єкти, які беруть участь у створенні
виконуваний, але часто малоймовірно, що ви створите файл точно однаковий
виконуваний з ідентичних входів. Знову ж таки, у цьому випадку використання кешу збірки є марною тратою
дискового простору та часу, тому має сенс відключити його.

Іноді файл може бути дуже швидко створений, і його просто марно розмістити
кеш збірки, оскільки його можна створити так само швидко, як і скопіювати. Ви можете захотіти
вибірково вимикати кешування цих файлів.

Ви можете вимкнути кеш збірки для певних правил, вказавши ": build_cache none".
правило, ось таке:

наш_виконуваний файл: dateStamp.o main.o */*.so
: build_cache немає
$(CC) $(LDFLAGS) $(входи) -o $(вихід)

Цей прапор означає, що будь-які результати цього конкретного правила ніколи не будуть поміщені в
build cache, і makepp ніколи не намагатиметься витягнути їх із кешу збірки.

Як до управляти a будувати cache
makepp_build_cache_control команда ...
mppbcc команда ...

makepp_build_cache_control, mppbcc це утиліта, яка керує створенням кешів для makepp.
Що makepp_build_cache_control do визначається першим словом його аргументу.

Насправді цей невеликий сценарій є обгорткою для наступної команди, яку ви, можливо, захочете
зателефонуйте безпосередньо до своїх завдань cron, де може знадобитися шлях до "makeppbuiltin":

makeppbuiltin -MMpp::BuildCacheControl команда ...

Ви також можете використовувати ці команди з make-файлу після їх завантаження з префіксом «&» як
наведено нижче для прикладу "створити":

perl { use Mpp::BuildCacheControl } # Це модуль Perl, тому використовуйте замість include.

мій_кеш:
&create $(CACHE_OPTIONS) $(output) # Викликати завантажений вбудований модуль.

build_cache $(prebuild my_cache)

Допустимі команди, які також мають кілька стандартних параметрів, описаних у
makepp_builtins, це:

створювати [варіант ...] шлях/до/кеш ...
Створює кеш збірки з заданими параметрами. Допустимі параметри:

Стандартні параметри: "-A, --args-file, --arguments-file=filename, -v, --verbose"

-e група
--extend=група
--extend-group=група
Додайте новий кеш збірки до "групи". Це, можливо, було окремо
створити кеш до цього моменту.

-f
--сила
Це дозволяє створити кеш, навіть якщо шлях/до/кеш вже існувала. Якби це було
файл, який він видаляється. Якщо це був каталог, він використовується повторно, з будь-яким
вміст, який він мав.

-p
--бажано
Ця опція має сенс лише в тому випадку, якщо у вас є створені кеші в групі, які дозволяють
жорстке посилання на символічні посилання. У цьому випадку очищення перемістить члени до
бажаний диск. Ви можете створити кілька кешів у групі за допомогою цієї опції в
у цьому випадку файли будуть перенесені до них випадковим чином.

-s n1,n2,...
--subdir-chars=n1,n2,...
Контролює, скільки рівнів підкаталогів створюється для зберігання кешованих файлів,
і скільки файлів буде в кожному підкаталозі. Перший n1 персонажів
filename утворюють назву каталогу верхнього рівня та символи з n1 до n2 форму
ім'я каталогу другого рівня тощо.

Файли в кеші збірки називаються за допомогою хешів MD5 даних, які використовує makepp
кожне ім'я файлу складається з 22 цифр базової 64 плюс оригінальне ім'я файлу. Якщо кеш збірки
ім'я файлу 0123456789abcdef012345_module.o, він фактично зберігається в збірці
кеш як 01/23/456789abcdef012345_module.o якщо ви вкажете "--subdir-chars 2,4".
Фактично, "--subdir-chars 2,4" є за замовчуванням, який призначений для гігантського кешу збірки
з максимально 4096 каталогів з 416777216 підкаталогами. Навіть "--subdir-chars 1,2" або
"--subdir-chars 1" заведе вас досить далеко. На файловій системі, оптимізованій для величезних
каталогів, ви можете навіть сказати "-s ''" або "--subdir-chars=" для зберігання всіх файлів
верхній рівень.

-m завивки
--mode=завивки
--access-permissions=завивки
Вказує права доступу до каталогу, коли файли додаються до збірки
кеш. Якщо ви хочете, щоб інші люди поміщали файли у ваш кеш збірки, ви повинні зробити
це груповий або всесвітній запис. Дозволи необхідно вказувати за допомогою вісімкового позначення.

Оскільки це дозволи до каталогу, якщо ви надаєте будь-який доступ, ви також повинні надати
запустіть доступ, або ви отримаєте купу дивних збоїв. Тобто 0700 означає це
тільки цей користувач може мати доступ до цього кешу збірки. 0770 означає, що цей користувач і
будь-хто в групі може мати доступ для запису до кешу збірки. 0777 означає це
будь-хто може мати доступ до кешу збірки. Розумні вісімкові цифри — 7
(запис), 5 (читання) або 0 (немає). Також можливо 3 (запис) або 1 (читання), що дозволяє
кеш, який буде використаний, але не для перегляду, тобто це було б складніше для a
зловмисника, щоб знайти імена файлів для маніпулювання.

У групі кешів збірки кожен має своє значення для цього, тому ви можете застосувати
різні дозволи на запис на різних дисках.

Якщо ви не вкажете дозволи, ваші дозволи umask під час створення
застосовувати протягом усього життя кешу збірки.

очистити [варіант ...] /шлях/до/кешу ...
Очищає кеш. Makepp ніколи не видаляє файли з кешу збірки; тобі вирішувати
щоб видалити файли за допомогою цієї команди. Для багатокористувацьких кешів це може зробити sysop.

Видаляються лише файли з кількістю посилань 1 (оскільки в іншому випадку файл не отримує
у будь-якому випадку фізично видалено - ви просто розпакуєте файл, який, очевидно, є
все ще цікавить, тому може бути ще хтось). Наведені вами критерії стосуються
фактично кешовані файли. Кожен інформаційний файл збірки буде видалено, коли його основний файл буде видалено.
Порожніх каталогів не залишиться. Незалежно від кількості посилань і параметрів, які ви можете
дайте, будь-який файл, який не відповідає його інформаційному файлу збірки, буде видалено, якщо він старіший
ніж запас безпеки в 10 хвилин.

Наступні параметри беруть як аргумент специфікацію часу. Часові характеристики починаються з
"+" означає давно, "-" означає нещодавно або нічого між значенням
номер, який ви даєте, і ще один. За замовчуванням числа, які можуть бути дробовими, є днями.
Але за ними може стояти одна з літер "w" (тижні), "d" (дні, за замовчуванням),
«h» (години), «m» (хвилини) або «s» (секунди). Зауважте, що дні – це просто 24 реальні години
ігноруючи будь-які зміни між літнім та зимовим часом. Приклади:

1 від 24 до 48 годин тому
24 години від 24 до 25 годин тому
0.5 дня від 12 до 36 годин тому
1 неділю від 7 до 14 разів 24 години тому
-2 менше 48 годин тому
+30 м більше 30 хвилин тому

Усі наступні варіанти поєднуються з «і». Якщо ви хочете кілька комплектів
комбінації з "або", ви повинні викликати цю команду кілька разів з різними наборами
варіанти. Спочатку зробіть ті, де очікуєте найбільше видалення, а потім інші
бути швидшим.

Стандартні параметри: "-A, --args-file, --arguments-file=filename, -v, --verbose"

-a spec
--Час spec
-- час доступу spec
Востаннє читали файл. Для пов’язаного файлу це може статися будь-коли.
В іншому випадку це останній раз, коли файл копіювався. На поганих системах
це також може бути час останнього резервного копіювання на стрічку або створення індексу пошуку. Ви можете
спробуйте виключити кеш з таких операцій.

Деякі файлові системи не підтримують поле atime, і навіть якщо файлова система
іноді люди вимикають час доступу до своїх файлових систем, тому що це додає
багато додаткового дискового вводу/виводу, який може бути шкідливим для ноутбуків із батарейним харчуванням або в
оптимізація швидкості диска. (Але це потенційно можна виправити - див
Коментарі UTIME_ON_IMPORT у Mpp/BuildCache.pm.)

-b
-- суміш
--групи сумішей
Зазвичай кожен /шлях/до/кешу вказана вами група буде розглядатися окремо
кешів, до яких він належить. Кожна група отримує лікування лише один раз, навіть якщо ви вказали
кілька шляхів з однієї групи. За допомогою цієї опції ви тимчасово змішуєте все
визначені вами групи в одну групу.

Виконання цього для очищення може мати небажані наслідки, якщо ви можете жорстко посилатися на символічні посилання,
оскільки він може мігрувати членів з однієї групи в іншу. Подальші не змішані
очищає, може потім очистити їх від початкової групи передчасно.

-c spec
--ctime spec
--час зміни spec
Час останньої зміни inode файлу. У ситуації з’єднання це може бути
час, коли останній користувач повторно створив файл по-іншому, розірвавши своє посилання
кеш. Це також може бути момент, коли параметр «--set-user» нижче мав
змінити користувача. На системах, що працюють добре, це також може бути час, коли
останнє резервне копіювання на стрічку або створення індексу пошуку закрили свої сліди, скинувши параметр
Час.

-m spec
--mtime spec
--час модифікації spec
Час останньої зміни файлу. Як пояснюється в іншому місці, це не рекомендується
щоб makepp оновив файл. Тож останньою модифікацією зазвичай є час
створення. (Але в майбутньому makepp може за бажанням оновити mtime, коли
видалення файлів. Це робиться для того, щоб посилання на файлові системи або копії без часу
відстежено.)

-g група
--newgrp=група
--нова-група=група
Встановіть ефективний і реальний ідентифікатор групи на групу (ім’я або число). Може бути тільки root
здатний це зробити. Це потрібно, коли ви використовуєте згруповані кеші збірки
надати доступ для запису до кешів на основі ідентифікатора групи. Зазвичай цього не буде
root's group і, таким чином, реплікація створила б каталоги, які не можна записувати без цього
варіант.

Ця опція названа на честь еквівалентної утиліти "newgrp", яку, на жаль, нелегко
використовуватися в завданнях "Cron" або подібних налаштуваннях.

-i
--build-info
--build-info-check
Переконайтеся, що інформація про збірку відповідає учаснику. Такий тест досить дорогий
ви можете не надавати цю опцію вдень.

-l
--перевірка символічного посилання
--symbolic-link-check
Ця опція робить «чистим» читання кожного символічного посилання, яке не має зовнішнього жорсткого пристрою
посилання, щоб переконатися, що воно вказує на потрібного учасника. Так як це дещо
дорого, рекомендується робити це тільки вночі.

-M spec
--в часі spec
--incoming-modification-time spec
Час останньої зміни для файлів у вхідному каталозі. Цей каталог є
використовується для тимчасових файлів із специфічними для процесів іменами, які можна записати вільно
одночасний доступ, а потім атомарно перейменований в активну частину кешу.
Зазвичай файли живуть тут лише стільки, скільки потрібно для їх запису, але вони можуть
осиротіти, якщо процес, який їх записує, завершується аномально до цього
можна їх видалити. Ця частина кешу очищається спочатку, тому що посилання враховується
на активну частину кешу можуть неправомірно впливати осиротілі файли.

Специфікація часу для "--incoming-modification-time" має починатися з "+" і значення за замовчуванням
до "+2h" (вважається, що файли віком не менше 2 годин осиротілі).

-w
-- робочі дні
Це впливає на підрахунок параметрів часу. Вихідні ігноруються, наче вони
не були там. Виняток становить, якщо ви надаєте цю опцію на вихідних. Тоді це
вихідні зараховуються нормально. Тож ви можете використовувати його в cronjobs, які запускаються з вівторка
до суботи. Літній час ігнорується. Тож літні вихідні можуть піти з суботи
з 1:00 до 1:00 понеділка або зимові вихідні в південній півкулі з 23:00 п'ятниці до
Неділя 23:00 або наскільки ваш часовий пояс змінює час. Свята також є
не враховано.

-p perlcode
--perl=perlcode
--присудок=perlcode
TODO: адаптуйте цей опис до змін групи!

Це швейцарський офіцерський ніж. The perlcode викликається у скалярному контексті один раз
для кожного запису кешу (тобто за винятком каталогів та файлів метаінформації). це є
викликаний у «шуканій» функції «File::Find», тому подивіться там для змінних, які ви можете
використовувати. Було виконано "lstat", тому ви можете використовувати дескриптор файлу "_".

If perlcode повертає "undef", ніби його там не було, тобто іншого
варіанти вирішують. Якщо він повертає true, файл видаляється. Якщо він повертає false, то
файл зберігається.

-s spec
--розмір spec
Специфікація розміру файлу працює так само, як і специфікації часу, зі знаком «+».
більше або "-" для менших, за винятком того, що одиниці вимірювання мають бути "c" (байти,
за замовчуванням), «k» (кілобайти), «M» (мегабайти) або «G» (гігабайти).

-u користувач
--user=користувач
--set-user=користувач
Цей варіант дуже різний. Він не говорить, коли потрібно видалити файл. Замість цього
застосовується до файлів, які не видаляються. Зауважте, що в багатьох системах тільки root
дозволяється встановлювати користувача файлу. Перегляньте розділ «Застереження щодо роботи з build
кеш", чому вам може знадобитися змінити власника на нейтрального користувача, якщо ви використовуєте
дискові квоти.

Ця стратегія працює лише в тому випадку, якщо ви можете довіряти своїм користувачам, що вони не підривають збірку
кеш для зберігання довільних (тобто нерозроблених) файлів за межами їх дискової квоти.
Право власності на пов’язаний файл метаданих зберігається, тому ви завжди можете бачити
хто кешував файл. Якщо вам потрібна ця опція, її може знадобитися надати кілька
разів протягом дня.

Існують різні можливі стратегії, залежно від того, скільки у вас місця та від того, скільки у вас є
чи містить кеш збірки пов’язані файли, чи користувачі мають лише копії.
Кілька стратегій можна комбінувати, називаючи їх одну за одною або по-різному
разів. Команда «показати» покликана допомогти вам знайти відповідну стратегію.

Щоночі (з вівторка по суботу) запуск може містити "--atime +2" (або "--mtime"
якщо у вас немає часу), видалення всіх файлів, які ніхто не читав протягом двох днів.

Якщо ви використовуєте посилання, ви також можете запобігти швидкому марному росту, яке відбувається, коли
послідовні зміни заголовків, які ніколи не контролюються версіями, призводять до великої кількості об'єктів
швидко створюється. Щось на кшталт погодинного пробігу з "--mtime=-2h --ctime=+1h"
вдень зловить тих хлопців, яких автор видалив менше ніж за годину,
і з тих пір ніхто більше не хотів.

Показувати [варіант ...] /шлях/до/кешу ...
Це свого роду рекурсивна команда "ls -l" або "stat", яка показує оригінального власника
також, коли було змінено власника кешованого файлу та файлу метаданих
зберігає початкового власника (згідно з "clean --set-user"). Він показує дані файли, або
все в наданих каталогах.

Поля, у короткій стандартній та довгій багатослівній формі:

РЕЖИМ, режим
Вісімковий режим кешованого файлу, який зазвичай є таким, яким він був поміщений, мінус
записати біти.

EL, внутр. посилання
Кількість зовнішніх жорстких посилань на всіх членів групи разом.
Лише якщо значення дорівнює 0, файл придатний для очищення.

C, копії (тільки для згрупованих кешів збірки)
Кількість копій ідентичного файлу в усіх кешах збірки. В ідеалі це
є одним із систем, які дозволяють жорстке посилання на символічні посилання, але це можливо
тимчасово неможливо, оскільки є зовнішні посилання на більше ніж одну копію
(у цьому випадку ми втратимо кількість посилань, якщо його видалимо.

S, символічні посилання (лише для згрупованих кешів збірки)
Кількість символічних посилань між кешами збірки. В ідеалі це кількість
створювати кеші мінус один на системах, які дозволяють жорстке посилання на символічні посилання.
Але, як пояснювалося для попереднього поля, може бути більше копій, ніж необхідно,
і, таким чином, менше посилань.

UID Власник кешованого файлу. Це можна змінити за допомогою параметра "clean --user".

BI-UID
Власник інформаційного файлу збірки. Це не змінюється чистим, дозволяючи бачити
хто першим створив файл.

SIZE
Розмір (одної копії) в байтах.

atime, mtime, ctime
У довгій багатослівній формі ви отримуєте час доступу (читання) до файлу, модифікацію
time та час зміни inode (наприклад, коли деякий користувач видалив своє зовнішнє посилання на
кешований файл). У короткій стандартній формі ви отримуєте лише один із трьох разів
у трьох окремих колонках:

AD, MD, CD
День тижня доступу, зміни або зміни inode.

ADATE, MDATE, CDATE
Дата доступу, модифікації або зміни inode.

ATIME, MTIME, CTIME
Час дня доступу, модифікації або зміни inode.

ЧЛЕН
Повний шлях до кешованого файлу, включаючи ключ, із кореня кешу.

За допомогою "-v, --verbose" інформація, показана для кожної команди, дозволяє отримати
враження, які варіанти надати команді «чиста». Часи показано в
читабельну форму, а також кількість днів, годин або хвилин вік цього файлу
щойно перевищила. Якщо ви подвієте варіант, ви отримаєте додатково інформацію для кожного
член групи.

Стандартні параметри: "-A, --args-file, --arguments-file=filename, -f, --force, -o,
--output=ім'я файлу, -O, --outfail, -v, --verbose"

-a
--Час
-- час доступу
Показувати час доступу до файлу, а не час модифікації файлу в неповному режимі.

-b
-- суміш
--групи сумішей
Зазвичай кожен /шлях/до/кешу вказана вами група буде розглядатися окремо
кешів, до яких він належить. Кожна група отримує лікування лише один раз, навіть якщо ви вказали
кілька шляхів з однієї групи. За допомогою цієї опції ви тимчасово змішуєте все
визначені вами групи в одну групу.

-c
--ctime
--час зміни
Показувати час зміни інформації inode замість часу модифікації файлу в неповному вигляді
Режим.

-d
--видаляється
Показувати лише файли, які можна видаляти, тобто ті, у яких кількість зовнішніх посилань дорівнює 0.

-p модель
--шаблон=модель
Викрійки є шаблоном імені файлу в стилі bash (тобто ?, *, [], {,,}), який відповідає
імена членів після символу підкреслення, що відокремлює їх від ключа.

-s список
--сортувати=список
У невичерпному режимі змініть порядок сортування. Список не чутливий до регістру
Порядок заголовків стовпців через кому або пробіл. Є два особливих випадки:
"член" розглядає лише імена після ключа, тобто імена файлів такими, якими вони є
за межами кешу. І є спеціальна назва «вік», які групують які
відображаються дата та час. Цей параметр за замовчуванням має значення "член, вік".

Якщо у вас є величезний кеш, сортування якого займає нестерпно багато часу або потребує більше
пам’яті, ніж дозволено вашим процесам, ви можете пропустити сортування, вказавши порожній
список

статистика [варіант ...] /шлях/до/кешу ...
Це виводить кілька таблиць статистичних даних про вміст кешу збірки. Кожен стіл
ділиться на три групи стовпців. Перший стовпець відрізняється для кожної таблиці і є
заголовок рядка. Дві інші групи відносяться до суми SIZE файлів і кількість ФАЙЛИ
для цього заголовка. Каталоги та інформаційні файли збірки не враховуються, тому це a
трохи менше за розміром, ніж фактичне використання диска, і приблизно вдвічі за кількістю файлів.

Кожна з двох останніх груп складається з трьох пар стовпців, один стовпець із значенням,
і один для відсотка від загальної суми, яку представляє це значення. Перша пара показує
або розмір файлів, або кількість файлів. Дві інші пари показують
КУМУЛЬодин раз від найменшого до найбільшого і один раз навпаки.

Перші три таблиці з першим стовпцем AD, CD or MD показати час доступу, inode
час зміни або час модифікації, згрупований за днями. Насправді дні – це 24-годинні блоки
відлік назад від часу початку команди stats. Рядок «0» першого
Таким чином, таблиця покаже суму розмірів і кількість файлів, до яких було звернено доступ менше ніж за день
тому. Якщо тоді не було доступу до файлів, рядка «0» не буде. Ряд «1» у третьому
У таблиці буде показано файли, змінені (тобто записані в кеш збірки) між 24 і 48
годин тому.

Наступний стіл, EL, показує зовнішні посилання, тобто скільки дерев побудови спільно використовують файл
кеш збірки. Це показник корисності кешу збірки. На жаль тільки
працює, коли розробники мають кеш buld на власному диску, інакше вони повинні скопіювати
який не залишає глобального сліду. Чим більше вмісту має більшу кількість зовнішніх посилань, тим
більша користь від кешу збірки.

Знову наступний стіл EL, показує ту ж інформацію, що й попередня, але зважена
за кількістю зовнішніх посилань. Кожен байт або файл із зовнішнім посиланням дорівнює одному
вважається одним. Але якщо рахунок дорівнює десяти, значення рахуються десять разів. Ось чому
заголовки змінюються на * РОЗМІР та *ФАЙЛИ. Це гіпотетична величина, яка показує, як
багато використання диска або кількість файлів, якби всі використовувалися одні й ті самі дерева збірки
немає кешу збірки.

Ще один стіл, C:S копії символічних посилань, відноситься лише до згрупованих кешів. В ідеалі все
члени існують в одній копії, а символічних посилань на одне менше, ніж кешів у групі.
Символьні посилання залишаються "0", доки очищення не повториться. Може бути більше однієї копії,
якщо кілька людей створили ідентичний файл до його тиражування, або якщо
реплікація перемістила файл на бажаний диск, але вихідний файл все ще був у ньому
використовувати. Зайві копії стають символічними посиланнями, коли очищення виявляє, що в них більше немає
зовнішні посилання.

Стандартні параметри: "-A, --args-file, --arguments-file=filename, -v, --verbose"

-h
--години
Відобразіть перші три таблиці з більшою деталізації. Заголовки стовпців
перейти AH, CH or MH відповідно.

-p модель
--шаблон=модель
Викрійки є шаблоном імені файлу в стилі bash (тобто ?, *, [], {,,}), який відповідає
імена членів після символу підкреслення, що відокремлює їх від ключа. Вся статистика
обмежено відповідними файлами.

Застереження робочий з будувати кеш-пам'ять
Створення кешей не працюватиме належним чином за таких обставин:

· Якщо команда makepp виконує лише для створення файлу поновлення файл і
не будує його свіжим, то ви повинні $NOT використовувати кеш збірки. (Прикладом є а
команда для оновлення модуля в статичній бібліотеці (архівному файлі або файлі з файлом
продовження .a). Як пояснюється в makepp_cookbook, на сучасних машинах це майже
завжди погана ідея оновлювати архівний файл - краще відновити його з нуля
кожного разу з різних причин. Це ще одна причина не оновлювати файл
archive file.) Причина в тому, що якщо кеш збірки розташовано на
та ж файлова система makepp створює жорстке посилання, а не копіює файл. Якщо ти тоді
згодом змінити файл, файл, який makepp має у кеші збірки, буде
насправді бути змінений, і ви потенційно можете зіпсувати чиюсь компіляцію.
На практиці makepp зазвичай може виявити, що файл був змінений з моменту його створення
поміщено в кеш збірки, і він не використовуватиме його, але іноді насправді може не використовувати
виявити модифікацію.

· Для .o файли це може бути трохи неправильним, оскільки вони можуть (залежно від компілятора
та рівень налагодження) містять шлях до джерела, з якого вони були створені. Це може зробити
жорстке налагодження. Налагоджувач може змусити вас редагувати оригінальну копію творця
джерело, або навіть не знайти файл, якщо у творця більше немає копії. Makepp
може колись запропонувати можливість виправити шлях, що, звичайно, означатиме копію,
замість ефективного посилання.

· Будь-який інший файл, у якому є закодований шлях, не слід поміщати в кеш збірки
(якщо ви поділяєте кеш збірки між кількома ієрархіями каталогів або кількома
розробники). У цьому випадку результат збірки в іншому каталозі не є тим
так само, як якщо б він був у тому самому каталозі, тож вся концепція кешу збірки є
не застосовується. Це нормально, якщо ви вкажете шлях до каталогу в командному рядку, наприклад
це:

&echo prog_path=$(PWD) -o $(вихід)

тому що тоді командний рядок буде іншим, і makepp не буде неправильно витягувати
файл з кешу збірки. Але якщо командний рядок не відрізняється, то там
може бути проблемою. Наприклад,

echo prog_path=`pwd` > $(вихід)

не працюватиме належним чином.

· При використанні посилань і з багатьма активними розробниками одного проекту на одному диску,
Складання кешів може заощадити багато місця на диску. Але в той же час для окремих користувачів
може бути і протилежне:

Уявіть, що Чанг першим здійснив повну збірку. Приходить Чінг і отримує посилання на
всі ці файли. Чанг робить деякі фундаментальні зміни, які призводять до того, що більшість речей є
перебудований. Він перевіряє їх, Чонг перевіряє їх і отримує посилання на кеш збірки.
Chang знову вносить зміни, що призводить до третього набору файлів.

У цьому випадку, незалежно від того, яку стратегію очищення ви використовуєте, жодні файли не будуть видалені,
тому що всі вони досі використовуються. Проблема в тому, що всі вони належать Чангу,
що може змусити його досягти своєї дискової квоти, і він нічого не може з цим зробити
більшість систем. Перегляньте команду «clean --set-user» у розділі «Як керувати кешем збірки»
як системний адміністратор міг змінити файли на власника кешу без квот.

· Якщо ви використовуєте підписи мітки часу/розміру для перехресної перевірки цілі та її збірки
info (за замовчуванням), то можна отримати псевдонім підпису, у якому не
відповідні файли не будуть виявлені. Наприклад, значення інформації про збірку MD5_SUM
може не відповідати контрольній сумі MD5 цілі. Зазвичай це не проблема, т.к
в силу того факту, що ключі кешу збірки збігаються, ціль у кеші збірки
є замінним для цілі, яка б відповідала файлу інформації про збірку.
Однак, якщо у вас є дії правила, які залежать від інформації про збірку, це може допомогти вам
в біду (тому не робіть цього). Якщо вас це турбує, використовуйте --md5-check-bc
варіант.

Одночасно доступ
Кеші побудови повинні підтримувати одночасний доступ, що означає, що реалізація має бути обов’язковою
бути толерантним до рас. Зокрема, файл може застаріти (видалити) між часом
makepp вирішує імпортувати ціль і час завершення імпорту.

Крім того, деякі люди використовують кеш збірки через NFS, що не обов’язково є узгодженим. в
іншими словами, порядку створення файлів і видалення записувачем на одному хості не буде
обов'язково збігаються з порядком, який бачить читач на іншому хості, а отже, рас не може
можна вирішити, звернувши особливу увагу на порядок операцій з файлами. (Але є
зазвичай тайм-аут кешу NFS становить близько 1 хвилини, що гарантує, що запис не займе
довше, ніж цей проміжок часу, щоб донести його до всіх читачів. Крім того, зазвичай в
практикуйте, що принаймні 99% записів видно скрізь протягом 1 секунди.) Через це,
ми повинні терпіти випадок, у якому кешована ціль та її інформаційний файл не здаються
відповідати. Крім того, існує особлива гонка, яка може виникнути, коли файл є
одночасно старіють і замінюють, у яких файли не відповідають навіть після NFS
очищення кешу. Здається, цього не уникнути.

Використовуйте makepp_build_cache_control онлайн за допомогою служб onworks.net