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

ПРОГРАМА:

ІМ'Я

metaconfig - генератор сценаріїв налаштування

СИНТАКСИС

metaconfig [ -dhkmostvwGMV ] [ -L реж ]

ОПИС

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

Метаконфігурація діє з набору одиниць які визначають все, про що знає metaconfig
портативність. Кожен блок є автономним, і його не потрібно ніде реєструвати
крім включення до загальнодоступного каталогу U або вашого приватного каталогу U. Якщо
пакет dist (частиною якого є metaconfig) встановлюється в LIB, потім загальнодоступний U
каталог LIB/dist/mcon/U. На цій машині каталог LIB – /usr/share/dist. Ваш
приватний каталог U, якщо він у вас є, знаходиться в каталозі верхнього рівня вашого пакета.
Перш ніж ви зможете бігти metaconfig ви повинні зробити кілька речей:

· Створіть файл .package у каталозі верхнього рівня пакета, запустивши packinit.
Ця програма запитає вас про ваш пакет і запам'ятає, що ви йому скажете
всі програми dist можуть бути розумними.

· Зверніться до Глосарія (у LIB/dist/mcon) і напишіть ваші сценарії оболонки та програми на C
з точки зору символів, які metaconfig знає, як визначити. Вам не потрібно розповідати
metaconfig, які символи ви використовували, оскільки metaconfig розбере це за вас.

· Згенеруйте будь-які сценарії .SH, необхідні для написання файлів Makefiles або сценаріїв оболонки, які залежать
на значеннях, визначених Configure. Є програма під назвою makeSH що вам допоможе
перетворити звичайний сценарій у шаблон script.SH; деяке редагування все одно потрібно буде
виконується над отриманим файлом .SH, щоб перемістити змінну конфігураційну частину в файл
верхня частина сценарію (дивіться вбудовані коментарі, згенеровані makeSH у вашому .SH
файл).

· Створіть файл MANIFEST.new у каталозі верхнього рівня, у якому перераховано всі файли
ваш пакет. Цей файл залишиться приватним і не буде частиною фіналу
розповсюдження. (Для зручності файл MANIFEST буде використовуватися metaconfig if
ще немає файлу MANIFEST.new.) Ім'я файлу має бути першим полем у кожному
лінія. Після пробілів ви можете додати короткий коментар з описом вашого файлу. Тільки
вихідні файли повинні бути перераховані там. Спеціальний файл patchlevel.h (який
обробляється та підтримується інструментами виправлення - див поплескування(1)) має бути частиною
MANIFEST.new, але деякі інструменти можуть ігнорувати його. Як правило,
там повинні бути перераховані лише файли, які підтримує RCS patchlevel.h файл істота
один важливий виняток.

· За бажанням, ви можете створити файл MANIFEST, який буде експортованою версією
вашого МАНІФЕСТУ.новий. Цей файл має бути частиною випуску, тобто вказати в обох
ваш MANIFEST.new і сам MANIFEST. Один з metaconfig одиниці знає про це
файл і змусить Configure виконати перевірку випуску, переконавшись, що всі файли
перераховані там є частиною розповсюдження. Файли MANIFEST і MANIFEST.new повинні
бути чіткими, а не посиланнями.

· Скопіюйте будь-які файли .U, які ви хочете змінити, до вашого приватного каталогу U. Будь-які файли .U
у вашому приватному каталозі U буде використовуватися замість загальнодоступного каталогу U
каталог. Наприклад, одним із способів примусового включення будь-якого блоку є копіювання End.U
у ваш каталог .U та додайте назву одиниці, від якої ви хочете залежати
кінець рядка ?MAKE:. Певні одиниці можна ТІЛЬКИ таким чином примусити, а саме
ті у формі Warn_*.U та Chk_*.U. Ви також можете налаштувати певні параметри за замовчуванням
Налаштуйте змінні, скопіювавши Myinit.U до приватного каталогу U вашого пакета та
встановлення змінних у цій одиниці.

Тепер ви готові бігти metaconfig. Це створить a Конфігурувати файл, і за бажанням a
config_h.SH файл (якщо ваші джерела використовують символи C). Згенеровані файли будуть
за потреби автоматично додається до вашого MANIFEST.new. Не забудьте оновити свою
Однак файл MANIFEST.

Щоб створити нові одиниці, виконайте такі дії:

· Скопіюйте подібну одиницю в новий файл .U. Вибране ім’я має бути ім’ям a
змінна, створена одиницею, хоча це лише зручність для вас, а не a
вимога. Він має містити 12 або менше символів, щоб запобігти порізанню імені файлу.
Насправді, це, ймовірно, має бути 10 або менше, щоб ті, хто хоче використовувати RCS, могли мати
a .U,v на кінці без рубання. Metaconfig використовує регістр першої літери до
визначте, чи справді якась змінна створюється цим блоком, тому не користуйтеся великою літерою
ім'я одиниці, якщо він має створювати змінну оболонки.

· Відредагуйте новий файл .U, щоб зробити те, що ви хочете. Перший рядок ?MAKE: вказує на
залежності; перед двокрапкою остаточного списку всі змінні, які визначає цей блок, і
після останнього двокрапки всі змінні (або інші одиниці), від яких залежить ця одиниця.
Дуже важливо, щоб ці списки були точними. Якщо залежність необов’язкова і a
можна використовувати значення за замовчуванням, ви повинні поставити перед залежністю знак «+». The
відповідний блок не буде завантажено для обчислення символу, якщо це дійсно не потрібно
іншим підрозділом.

· Наскільки це можливо, параметризуйте свій блок на основі змінної оболонки, визначеної на
?INIT: рядки. Це перемістить визначення змінних до блоку Init.U, де
їх можна замінити визначеннями в Myinit.U, який включено після Init.U.

· Додайте визначення будь-яких бажаних символів C у вигляді рядків ?H:. Рядок, що починається з
?H:?%<: у файлі .U буде додано до остаточного файлу config.h тоді і тільки тоді, коли
metaconfig вирішує, що цей блок потрібен. %< означає назву підрозділу,
яке також є ім’ям файлу (без .U), якщо ви дотримувалися
конвенції. Завжди ставте коментар до кожного рядка ?H: у випадку, якщо одна зі змінних
заміни раніше на рядку починає коментар, не закінчуючи його. Будь-яка оболонка
змінна, яка починається з d_, може зробити це, тому будьте обережні. Якщо ви пропустите ?%<:, то
metaconfig спробує інтуїтивно зрозуміти символ, визначення якого потрібне перед будь-яким
включення в config.h.

· Додайте визначення глосарію як ?S: рядки для змінних оболонки та ?C: рядки для C
змінні препроцесора. Для прикладів див. поточну одиницю. Це ДУЖЕ важливо
починайте кожен запис з імені символу, вирівняного ліворуч, і закінчуйте кожен запис символом ?C:. або
?S:. лінія. Алгоритм, який перекладає записи символів препроцесора C для
Від цього залежить глосарій у коментарях для config.h.

· Переконайтеся, що порядок всіх ваших ? рядки правильні. Правильний порядок:

?RCS: і ?X: в основному просто коментарі
?MAKE: залежності metaconfig
?Y: директива розташування пристрою
?S: визначення оболонок глосарію
?C: глосарій C визначень
?H: визначення config.h
?M: визначення confmagic.h
?W: розшукувані символи
?V: видимі символи
?F: файли, створені цим пристроєм
?T: використовуються тимчасові символи оболонки
?D: необов'язкові залежності значення за замовчуванням
?O: використовується для позначення застарілих одиниць
?LINT: підказки metalint
?INIT: ініціалізація символів оболонки

Ось приклад, щоб показати порядок рядків і різні дозволені формати:

?RCS: $RCS-Id$
?RCS: інформація про авторські права
?RCS: $RCS-Log$
?X:
?X: Надуманий приклад
?X:
?MAKE:d_один два: три +чотири П'ять
?MAKE: -pick add $@ %
?Y: ЗА УМОВЛЕННЯМ
?S:d_one:
?S: перший символ оболонки, умовно визначає ONE.
?S:.
?S:два:
?S: символ другого оболонки, значення для ДВА.
?S:.
?C:ONE:
?C: перший символ C.
?C:.
?C:ДВА:
?C: Другий символ C.
?C:.
?H:#$d_one ONE /**/
?H:#define TWO "$two"
?H:#$d_one ONE_TWO "$two"
?H:.
?M:flip: HAS_FLIP
?M:#ifndef HAS_FLIP
?M:#define flip(x) flop(x)
?M:#endif
?М:.
?W:%<:один_два
?V:p_one p_two:p_three
?F:файл ./ftest !tmp
?T:tmp вар
?D:two='undef'
?LINT: зміна три
?INIT:two_init='2'
: код оболонки, що реалізує модуль, наведено нижче
p_one='один'
p_two='два'
p_three=""

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

· Розмістіть пристрій у загальнодоступному або приватному каталозі U відповідно до необхідності.

· Повторити metaconfig.

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

Щоб додати нову програму для розташування:

· Відредагуйте Loc.U та додайте назву програми до рядка ?MAKE: (між
два двокрапки) і в loclist або trylist (залежно від того, чи є програма
обов'язкове чи ні).

· Повторно запустіть metaconfig.

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

Примітки щодо запису файлів .U:

* Завжди використовуйте "rm -f", тому що є системи, де rm інтерактивний за замовчуванням.

* Не використовуйте "set -- ...", оскільки "--" не працює з кожною оболонкою. Використовуйте «set x ...;
зміна".

* Не використовуйте "unset ENV", оскільки unset не повністю переноситься. Натомість скажіть "ENV=''".

* Завжди використовуйте echo " " (з пробілом) через системи Eunice.

* Використовуйте тільки тест з -r, -w, -f або -d, оскільки це єдині портативні комутатори. в
зокрема, уникайте "test -x".

* Використовуйте лише програми, які постачаються з V7, щоб ви знали, що вони є у всіх.

* Використовуйте $contains, якщо ви хочете умовно виконати grep, оскільки не всі greps повертають a
розумний статус. Обов’язково переспрямуйте вихід на /dev/null, використовуючи '>/dev/null
2>&1'.

* Використовуйте «if test», а не «if [...]», оскільки не кожен sh знає останню конструкцію.

* Використовуйте сценарій myread для введення даних, щоб вони могли виконувати екранування оболонки та за умовчанням
оцінка. Загальна форма є

випадку "$grimble" в
'') dflt=452;;
*) dflt="$grimble";;
що С
rp='Скільки у вас гримблів?'
. ./myread
grimble="$ans"

* Використовуйте сценарій getfile, коли запитуєте шлях до файлу, щоб мати необов'язковий
~перевірка розширення імені та працездатності. Повний опис дивіться у підрозділі Getfile.U.

* Завжди ставте a

$startsh

у верхній частині кожного згенерованого сценарію, який буде запущено або отримано
Конфігурувати.

* Ніколи не припускайте поширених UNIX-ізмів, як-от той факт, що об'єктний файл закінчується на a .o та
на що закінчується назва бібліотеки .a. Використовувати $_o та $_a замість змінних (див
Unix.U).

* Виконуючи тест компіляції-посилання-виконання, завжди пишіть його так:

$cc $ccflags $ldflags try.c -o спробуйте $libs

оскільки деякі системи вимагають, щоб прапори зв'язування були вказані перед компіляцією
цільова (за винятком бібліотек кінцевого зв'язування).

* Видавайте важливі повідомлення на файловий дескриптор №4, використовуючи '>&4' для перенаправлення виводу.
Тільки ці повідомлення з’являться, коли -s перемикач надається Конфігурувати на
командний рядок (беззвучний режим).

* Завжди намагайтеся визначити, чи є функція найбільш специфічним способом – ні
скажіть "if bsd", коли ви зможете grep libc. Існує багато гібридних систем, і
кожен елемент повинен стояти або падати сам по собі.

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

* Якщо ви сумніваєтеся, встановіть значення за замовчуванням і запитайте. Нічого не припускай.

* Якщо ви вважаєте, що користувач помиляється, врахуйте той факт, що він може бути правий. Для
наприклад, він може запускати Configure в іншій системі, ніж він збирається використовувати
кінцевий продукт на.

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

.MT/*
Конфігурувати
Потрібні
Застарілий
конфігурувати
config_h.SH
confmagic.h
U/*
МАНІФЕСТ.нов

Крім того, Configure може знищити ці імена в каталозі, в якому він виконується:

UU/*
config.sh
config.h

ВАРІАНТИ

Наступні параметри розпізнаються metaconfig:

-d Увімкніть режим налагодження. Не дуже корисно, якщо ви не налагоджуєте metaconfig
себе.

-h Роздрукуйте довідкове повідомлення та вийдіть.

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

-m Припускайте багато пам’яті та місця підкачки. Це прискорить пошук символів
вихідні файли на значну кількість часу, за рахунок пам'яті
споживання...

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

-s Увімкніть беззвучний режим.

-t Символи сліду, як вони знайдені.

-v Увімкніть докладний режим.

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

-G Також надайте GNU конфігурувати-як передня частина до згенерованого Конфігурувати
сценарій, який також буде включено до розповсюдження. Це лише обгортка
навколо Конфігурувати сценарій, природно, але він дозволяє людям, знайомим з
Інструмент GNU, який не можна втратити, коли зіткнулися з новим дистрибутивом.

-L реж Замінити розташування бібліотеки за замовчуванням. Зазвичай корисний лише для metaconfig
супроводжуючим, щоб локально використовувати одиниці, що розробляються, замість
загальнодоступні. The реж вказано те, що містить одиниці
U каталог.

-M Дозволити виробництво a confmagic.h файл, щоб автоматично переназначити деякі добре-
відомі символи до іншої альтернативи, наприклад bкопія() переназначається
прозоро до memcpy() коли немає в наявності. Цей параметр увімкнено
автоматично, коли a confmagic.h файл існує в каталозі верхнього рівня.
Просто видаліть цей файл, якщо ви хочете назавжди вимкнути цю опцію.

-V Роздрукуйте номер версії та вийдіть.

Підручник

Цей (довгий) розділ є вступом до metaconfig, в якому ми дізнаємося все
основи. Якщо ви вже вмієте користуватися metaconfig, ви можете сміливо переходити до наступного
.

огляд
Зазвичай, коли ви хочете отримати якийсь вихідний пакет для компіляції на заданій у вас платформі
щоб відредагувати основний Makefile (якщо він є!), виберіть компілятор C, переконайтеся, що ви
мати відповідні бібліотеки, а потім запустити зробити команда. Якщо пакет прийнятний
добре написано, він буде компілюватися (без попередження :-). Сам по собі останній
речення є справжньою продуктивністю, оскільки враховуючи різноманітність платформ UNIX, доступних сьогодні
і різноманітність смаків, це означає, що автор упаковки глибоко заглибився
проблеми з визначенням правильного вибору з огляду на деякі стандартні проби, здогади та метушні
навколо з системою включає і типи.

Однак, незважаючи на весь свій талант, автор не може знати, що якась система має a
зламаний системний виклик, або що в деякій системній структурі не вистачає одного стандартного поля, або
просто чи існує даний файл включення чи ні. І я не розглядаю неявне
припущення, як-от тип, що повертається malloc () функція або наявність
перейменувати() системний виклик, щоб назвати декілька. Але ці знання необхідні для досягнення реального
портативність.

Тепер давайте не зловживати собою. Використання цієї інформації вимагає більших навичок, але це можливо
призвести до більш портативних програм, оскільки вони потім написані системно-незалежним способом
і покладається лише на той факт, що певне припущення є істинним або хибним для певної системи,
кожне припущення не пов’язане одне з одним. Тобто ми не кажемо: ми на а
BSD або ми в системі USG. Це все одно надто нечітко в наш час. Ні, ми хочемо
скажіть вихідному коду: ця система не має перейменувати() системний виклик і malloc ()
повертає a (недійсна *) value.

Metaconfig — це інструмент, який дозволить вам зробити саме це, з додатковою перевагою — ні
потрібно вручну редагувати Makefile, якщо все пройшло добре. За допомогою бігу metaconfig, ви створюєте
названий сценарій оболонки Конфігурувати. Багато зусиль було присвячено скрипту Configure
внутрішніх компонентів, щоб гарантувати, що він працюватиме на 99% існуючих оболонок, доступних на даний момент
написання. Configure досліджуватиме цільову систему, ставлячи запитання, якщо виникають сумніви
зібрати всі відповіді в один файл оболонки, який, у свою чергу, можна використовувати
автоматично генерувати налаштовані файли Makefiles та файли C, що включають.

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

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

Символи
Символи – це найважливіше в metaconfig світ. Вони найменші
розпізнаний об’єкт, як правило, слово, якому можна надати значення в кінці Configure
виконання. Наприклад, символ попереднього процесора C HAS_RENAME це metaconfig символ того
гарантовано визначається тоді і тільки тоді, коли перейменувати() присутній системний виклик. так само,
$ranlib Змінна оболонки буде встановлена ​​на ':' або 'ranlib' залежно від того, чи є
дзвонити до ranlib програма потрібна для замовлення файлу бібліотеки. Як це працює, не так
наразі важливо зрозуміти, що цим символам надано a життя
(тобто значення) на Конфігурувати виконання.

Використання символів є відносно простим. У вихідному файлі C ви просто використовуєте символ
значення, як директива попереднього процесора (наприклад: #ifdef HAS_RENAME) або, якщо символ
value — це рядок, безпосередньо як ви використовуєте макрос у C. І у файлі оболонки або a
Makefile, ви можете безпосередньо посилатися на символ оболонки.

Насправді, я брешу, тому що це не так магія, як попередній абзац
міг звучати. У файл C вам потрібно включити файл Configure-produced config.h файл і
ви повинні загорнути ваш сценарій оболонки або Makefile у файл .SH, і ви можете посилатися на оболонку
символ лише в частині заміни змінної цього файлу .SH. Докладніше про це пізніше.

Source Файли
Символи можуть з'являтися лише в обмеженому наборі вихідних файлів, тому що metaconfig буде лише
скануйте їх, шукаючи відомі символи, намагаючись зрозуміти, які одиниці знадобляться.
Ви можете використовувати символи C у вихідних файлах C, тобто файлах з a .c, .h, .y or .l розширення та
Символи оболонки шукають лише у файлах .SH.

Щоб отримати значення символу, файл C повинен містити спец config.h
файл, який створюється за допомогою Конфігурувати коли присутні символи C. І запускаються файли .SH
через оболонку, створюючи новий файл. Однак у верхній частині файлу .SH файл
спеціальний config.sh файл (також створюється за допомогою запуску Конфігурувати) є джерелом і змінним
застосовуються заміни. насправді, config.h виробляється шляхом запуску metaconfig- виробляється
config_h.SH файл, знову за допомогою заміни змінної. Тож ми розглянемо це а
трохи ближче, оскільки це серце цілого конфігурація схема...

Змінна Заміна
Існує конструкція оболонки під назвою тут документ що дозволяє команді приймати вхідні дані
вказано в самому скрипті. Цей вхід інтерпретується оболонкою як подвійний
рядок у лапках або рядок у одинарних лапках залежно від форми документа
специфікація.

Щоб указати тут документ, використовується маркер '<<', за яким слідує єдиний ідентифікатор. Від
далі рядки сценарію, що залишилися, утворюють вхідні дані для команди, аж до тут
документ знаходиться в рядку сам по собі. Заміна оболонки (включаючи змінну оболонки
заміни) виконується, якщо ідентифікатор не оточений одинарними лапками. Наприклад:

var='перший'
tar='другий'
echo "--> перший тут документ:"
кіт <
var='$var'
tar='$tar'
EOM
echo "--> другий тут документ:"
кіт <<'EOM'
echo $var
echo $tar
EOM
echo "--> end."

вироблятиме, коли проходить через оболонку:

--> перший тут документ:
var='перший'
tar='другий'
--> другий тут документ:
echo $var
echo $tar
--> кінець.

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

використання .SH Додайте нотатки до слайдів
Сценарій .SH зазвичай створюється шляхом запуску MakeSH скрипт іншого існуючого файлу,
перетворення файл в файл.SH. Розглянемо один приклад. Ось невеликий сценарій
(назвемо це intsize), який друкує одне повідомлення розміром Int тип даних в C.
На жаль, він має значення, закріплене в ньому, таким чином:

#!/ Бен / ш
intsize='4'
echo "На цій машині тип int - $intsize bytes"

Давай бігти makeSH на ньому, ввівши 'makeSH intsize'. Отримуємо сингл intsize.SH файл це
виглядає так:

case $CONFIG в
'')
якщо тест -f config.sh; потім TOP=.;
elif test -f ../config.sh; потім TOP=..;
elif test -f ../../config.sh; потім TOP=../ ..;
elif test -f ../../../config.sh; потім TOP=../../..;
elif test -f ../../../../config.sh; потім TOP=../../../..;
ще
echo "Не вдається знайти config.sh."; вихід 1
fi
. $TOP/config.sh
;;
що С
: Це змушує файли SH створювати ціль у тому самому каталозі, що й файл SH.
: Це для того, щоб make depend завжди знав, де знайти похідні SH.
справа "$ 0" в
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
що С
echo "Вилучення intsize (зі змінними замінами)"
: У цьому розділі файлу будуть зроблені заміни змінних.
: Перемістіть усе, що потребує конфігураційних підмінників, із !NO!SUBS! розділ до !ГРОК!ЦЕ!.
: Захистіть будь-які знаки долара та зворотні галочки, які ви не хочете інтерпретувати
: поставивши спереду зворотну косу риску. Ви можете видалити ці коментарі.
$spitshell >intsize <
$startsh
!ГРОК!ЦЕ!

: У наступних долларах і зворотних галочках не потрібен додатковий зворотний слеш.
$spitshell >>intsize <<'!NO!SUBS!'
intsize='4'
echo "На цій машині тип int - $intsize bytes"
!НІ!SUBS!
chmod 755 intsize
$eunicefix intsize

Перша частина цього сценарію (у випадок заява) намагається знайти config.sh
файл, щоб отримати його. The $CONFIG змінна за замовчуванням false, true коли
config.sh вже отримано (що було б у випадку, якби цей файл був запущений з
в Конфігурувати але не будемо плутати це питання).

Після config.sh у файлі були джерела, усі символи оболонки визначені Конфігурувати він має
набір. Ми знаємо, що досягти другого оператора case, що використовується для зміни поточного каталогу слід a
шлях використовуватися для досягнення цієї програми (наприклад, якщо ми сказали 'sh ../scripts/intsize.SH', ми
спочатку б запуститиcd ../скрипти' перш ніж продовжити). Якщо ви цього не розумієте, не розумійте
турбуйтеся про це.

Ось цікаве. Цей сценарій використовує $spitshell змінна, а це не так
щось ми знаємо...поки що. Якщо ви переглянете файл глосарію, ви побачите це
це відома змінна metaconfig. Якщо ви зробите цей файл частиною свого дистрибутива
(включивши його у файл MANIFEST.new, ми повернемося до цього пізніше) і запустіть
metaconfig, А потім Конфігурувати скрипт визначить відповідне значення для цієї змінної
і він буде встановлений config.sh. Те саме стосується $startsh і таємничий $eunicefix at
кінець. За розумною системою відповідна частина config.sh буде виглядати так:

spitshell='кішка'
startsh='#!/ Бен / ш'
eunicefix=':'

Ах! Ми добираємося туди. Тепер це виглядає знайомим. Ми стикаємося з синглом як командувати чий
вхідні дані надходять із інтерпольованого тут документа з інтерполяцією змінних, куди перенаправляється висновок
intsize. Значення буде таке $startsh, тобто '#!/ Бен / ш'. Поки що добре.

Потім ми досягаємо другого тут розширення документа, щоб отримати решту сценарію. Це
час, тут символ документа оточений одинарними лапками, тому вміст буде таким
дослівно додається до intsize файл. Отже, бігаючи 'sh intsize.SH', ми отримуємо
наступний вихід:

Вилучення intsize (зі змінними замінами)

і, подивившись на створений файл intsize, ми бачимо:

#!/ Бен / ш
intsize='4'
echo "На цій машині тип int - $intsize bytes"

це саме те, що ми мали на початку. Поки що це процедура без операції...
Але як чудово! Так буває (чиста випадковість, повірте мені!), що metaconfig знає
про $intsize символ оболонки. Перемістивши ініціалізацію intsize до змінної-
інтерпольована область сценарію .SH та ініціалізація її за допомогою Конфігурувати- обчислене значення,
і видалення тепер непотрібних коментарів, доданих користувачем makeSH, ми отримуємо:

case $CONFIG в
'')
якщо тест -f config.sh; потім TOP=.;
elif test -f ../config.sh; потім TOP=..;
elif test -f ../../config.sh; потім TOP=../ ..;
elif test -f ../../../config.sh; потім TOP=../../..;
elif test -f ../../../../config.sh; потім TOP=../../../..;
ще
echo "Не вдається знайти config.sh."; вихід 1
fi
. $TOP/config.sh
;;
що С
справа "$ 0" в
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
що С
echo "Вилучення intsize (зі змінними замінами)"
$spitshell >intsize <
$startsh
intsize='$intsize'
!ГРОК!ЦЕ!

$spitshell >>intsize <<'!NO!SUBS!'
echo "На цій машині тип int - $intsize bytes"
!НІ!SUBS!
chmod 755 intsize
$eunicefix intsize

Звичайно, запуск цього сценарію через оболонку знову виведе той самий сценарій. Але якщо
ми біжимо Конфігурувати на машині, де an Int зберігається як кількість 64 біта, config.sh волі
комплект intsize до 8 р intsize скрипт матиме потрібне значення та виведе:

На цій машині тип int становить 8 байт

що є правильним. Вітаю! Ми щойно налаштували сценарій оболонки!!

Виробництво config.h
Тепер ми можемо подивитися на шлях config.h виробляється з config_h.SH. Ми це знаємо
біг Конфігурувати виробляє a config.sh скрипт (як саме це робиться, не суворо
тут актуально, але для допитливих це ще одна заміна документа всередині
Конфігурувати сама по собі). The config_h.SH сам побудований metaconfig в той же час
Конфігурувати за умови, що ви використовуєте принаймні один символ C у своїх джерелах.

Давайте подивимося на деякі випадкові config_h.SH файл, щоб побачити, що насправді відбувається:

case $CONFIG в
'')
якщо тест -f config.sh; потім TOP=.;
elif test -f ../config.sh; потім TOP=..;
elif test -f ../../config.sh; потім TOP=../ ..;
elif test -f ../../../config.sh; потім TOP=../../..;
elif test -f ../../../../config.sh; потім TOP=../../../..;
ще
echo "Не вдається знайти config.sh."; вихід 1
fi
. $TOP/config.sh
;;
що С
справа "$ 0" в
*/*) cd `expr X$0 : 'X\(.*\)/'` ;;
що С
echo "Витяг config.h (із замінами змінних)"
sed < config.h -e 's!^#undef!/define!' -e 's!^#un-def!#undef!'
/*
* Цей файл створено за допомогою скрипту config_h.SH, який
* отримує свої значення з config.sh, який зазвичай створюється
* запущено Configure.
*
* Не соромтеся змінювати будь-яке з цього, якщо виникне необхідність. Зауважте, однак,
* що повторний запуск config.h.SH знищить усі внесені вами зміни.
* Для більш постійних змін відредагуйте config.sh і повторно запустіть config.h.SH.
*/

/* Час конфігурації: $cf_time
* Налаштовано: $cf_by
* Цільова система: $myuname
*/

#ifndef _config_h_
#define _config_h_

/* bcopy:
* Цей символ зіставляється з memcpy, якщо підпрограма bcopy() не є
* доступний для копіювання рядків.
*/
/* HAS_BCOPY:
* Цей символ визначається, якщо підпрограма bcopy() доступна
* копіювати блоки пам'яті. Ви не повинні використовувати цей символ під
* звичайні обставини і замість цього використовуйте безпосередньо bcopy(), що
* буде зіставлено з memcpy(), якщо bcopy недоступний.
*/
#$d_bcopy HAS_BCOPY /**/
#ifndef HAS_BCOPY
#ifdef bcopy
#un-def bcopy
#endif
#define bcopy(s,d,l) memcpy((d),(s),(l)) /* зіставлено з memcpy */
#endif

/* HAS_DUP2:
* Цей символ, якщо визначено, вказує на те, що процедура dup2 є
* доступний для повторюваних дескрипторів файлів.
*/
#$d_dup2 HAS_DUP2 /**/

/* I_STRING:
* Цей символ, якщо визначено, вказує програмі на C, що він повинен
* включати (системи USG) замість (системи BSD).
*/
#$i_string I_STRING /**/

#endif
!ГРОК!ЦЕ!

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

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

Це допомагає знати $d_* та $i_* змінні встановлені на 'визначати'або'undef' від
Конфігурувати, залежно від того, чи є функція чи файл включення в системі або
ні. Це означає:

#$d_bcopy HAS_BCOPY /**/

рядок буде розширено до:

#define HAS_BCOPY /**/

якщо для змінної $d_bcopy встановлено значення "define" або:

#undef HAS_BCOPY /**/

якщо для $d_bcopy встановлено значення 'undef', тому що функції не було. Однак це не так
що написано в config.h файл через sed фільтр, який ми вже бачили,
який перетворить другу форму на:

/*#define HAS_BCOPY /**/

Це зручна форма для подальшого редагування config.h тому що вам потрібно лише видалити
провідний '/*', якщо ви хочете перевизначити Конфігурувативибір. Так само ви можете додати сингл
'/*' на початку рядка '#define', щоб уникнути визначення певного символу.
Ось чому кожне визначення символу захищене кінцевим символом '/**/', щоб закрити початок
коментар відкривається '/*' (коментарі не вкладені в C).

Тепер трансформувати '#undef' в '/*#define' добре, але якщо ми хочемо насправді написати
"#undef", ми застрягли... якщо ми не напишемо це як "#un-def" і не дозволимо sed виправити це на '#undef'
під час виробництва config.h, що насправді тут і зроблено.

Те саме міркування стосується цих двох рядків:

#$d_dup2 HAS_DUP2 /**/
#$i_string I_STRING /**/

і припускаючи config.sh визначає:

d_dup2='визначити'
i_string='undef'

ми потрапимо у виробництво config.h:

#define HAS_DUP2 /**/
/*#define I_STRING /**/

Чиста як проточна вода? добре!

Тепер має бути очевидно, що шляхом включ config.h у всіх ваших вихідних файлах C, ви отримуєте
знаю, що Конфігурувати здогадався про вашу систему. Фактично, використовуючи ці символи, ви
написання налаштованого коду C, оскільки metaconfig буде знати, що вам потрібні ці символи і буде
створити відповідний config_h.SH файл, а також весь необхідний код в Конфігурувати до
обчислити для них правильне значення (призначивши значення пов'язаним змінним оболонки).

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

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

Припустимо, що ваш файл MANIFEST.new правильно налаштований і містить список усіх вихідних файлів, які ви бажаєте
налаштувати, і що ви запустили packint у вашому кореневому каталозі джерел, щоб створити файл a
.package файл, ви можете запустити metaconfig і ви отримаєте наступне:

$ metaconfig
Розміщення одиниць...
Вилучення списків залежностей з 312 одиниць...
Вилучення імен файлів (*.[chyl] і *.SH) з MANIFEST.new...
Створення файлу розшуку...
Сканування файлів .[chyl] на наявність символів...
Сканування файлів .SH на наявність символів...
Обчислення оптимального графіка залежності...
Створення приватного файлу make...
Визначення завантажуваних одиниць...
Оновлення файлу make...
Визначення правильного порядку для одиниць...
Створення конфігурації...
Пожертвувати.

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

Далі правильні імена файлів витягуються з файлів MANIFEST.new і a Потрібні файл є
вбудований: у цьому файлі перераховані всі символи C і символи оболонки, необхідні для цього пакета. ми
спочатку проскануйте файли C-типу на наявність символів C, а потім поширте залежності до них
пов'язані символи оболонки (збираються з рядків ?H:). Далі скануються файли .SH і нарешті
всі символи оболонки відомі.

Тимчасовий Makefile створюється, і metaconfig намагається зробити це зробити всі символи оболонки, щоб побачити
які команди (перераховані в другому рядку ?MAKE:) виконуються, і, таким чином, які блоки
дійсно потрібно. Додаткові одиниці, не потрібні іншим чином, видаляються, а другий Makefile є
згенеровано. Цього разу ми знаємо про всі підрозділи та їх відповідні замовлення, необов’язкові
вилучені одиниці та обчислені значення за замовчуванням для їхніх символів оболонки. The
Конфігурувати Після цього можна створити сценарій разом із config_h.SH. Були зроблені.

Умовні
Щоб весь процес був безпечним, необхідно дотримуватися відповідних умов. Є випадок
умова для одиниць та умова про найменування змінних.

Усі одиниці повинні мати свою першу літеру з нижнього регістру, якщо вони не є спеціальними. За
спеціальні, ми маємо на увазі, що вони насправді не визначають нові змінні оболонки, які можуть використовуватися
користувача у своїх файлах .SH, а скоріше одиниці, що виробляють сценарії або змінні оболонки, які повинні
використовуватися для внутрішнього застосування Конфігурувати сценарій. Типовими прикладами є Ініц.У файл, який є
ініціалізація головної змінної, або Myread.U який виробляє myread майже використаний сценарій
всюди в Конфігурувати коли користувачеві потрібно поставити запитання.

Неспеціальні одиниці потім поділяються на дві окремі групи: одиниці, що визначають змінні
пов'язаний із символом C і одиницями, що визначають власні змінні оболонки. Перша група
далі поділяється на змінні, пов’язані з файлами включення (їх назва починається з i_) і
змінні, пов’язані з іншими визначеннями (назва починається з d_). Друга група має
назви, що стоять самі за себе, наприклад cc.U визначає $cc змінна оболонки, значення якої є
компілятор C, який буде використано.

Спеціальні підрозділи іноді резервують для себе певну заздалегідь визначену змінну і повертають "результати"
в інших добре відомих змінних. Наприклад, myread сценарій від Myread.U
очікує підказки $rp, відповідь за замовчуванням у $dflt і розміщує відповідь користувача $ans.
Це не задокументовано на цій сторінці посібника: ви повинні піти і подивитися на сам пристрій
зрозуміти, які змінні використовуються і як одиницю використовувати.

використання Команда глосарій
Файл глосарію створюється автоматично makegloss скрипт, який витягує файл
інформація з рядків ?S:, ?C: і ?MAKE: і переформатує їх у алфавітний
відсортований глосарій. Важливо прочитати глосарій, щоб знати про символи, якими ви є
дозволено до використання. Однак глосарій не розповість вам, як ними користуватися. Зазвичай, це
вирішувати вам.

Одного дня ви, ймовірно, напишете свої власні одиниці і будете знати про них достатньо metaconfig
зробити це швидко та ефективно. Однак ніколи не забувайте правильно задокументувати свою роботу
рядки ?S: і ?C: або інші люди не зможуть повторно використовувати його. Згадайте про
час, коли ви мали лише глосарій і цю сторінку посібника для початку.

Висновок
Тепер, коли ви знаєте metaconfig основи, ви повинні прочитати ОПИС розділ, то
перейти до Посилання розділ, щоб дізнатися про всі кровові деталі, наприклад дозволені
синтаксис для рядків управління одиницями (рядків, що починаються з '?') або окремих команд MAKE
вам дозволено використовувати.

Посилання

Цей розділ документує внутрішні елементи metaconfig, в основному синтаксис одиниці, спец
одиниці, про які ви повинні знати, і файли підказок.

Загальне Блок синтаксис
Блок metaconfig розділений на дві окремі частини. Розділ заголовка (початок рядків
з '?') та розділом оболонки (код, який буде включено до Конфігурувати сценарій). це є
можна додати коментарі '?X:' будь-де в блоку, але інший '?' лінії (також
званий контроль ліній) мають сувору політику замовлення.

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

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

?RCS: безкоштовно текст
Використовується для коментарів RCS у верхній частині блоку.

?X: будь-який текст
Коментарі загального призначення. Може з’являтися в будь-якому місці блоку, але його потрібно вирівняти.
Для коментарів RCS, будь ласка, використовуйте форму коментарів ?RCS:.

?ЗРОБИТИ:символ список: залежність список [+опціонально]
Це перша лінія залежності. Перший символ список має перерахувати всі символи
побудований цим блоком (тобто значення якого обчислюється секцією оболонки блоку).
Символи мають бути розділені пробілами. Якщо визначений символ призначений лише для внутрішнього використання та
не повинно з'являтися в згенерованому config.sh файл, то йому має передувати a
'+' (не плутати з необов'язковими залежностями, визначеними далі). Другий
частина списку (після середини ':') є залежністю одиниці. У ньому має бути перераховано все
необхідні спеціальні підрозділи, а також усі символи, які використовує снаряд
виконання. Якщо символ необхідний, але його конфігураційне значення не є критичним, він
може передувати '+', і в цьому випадку вона називається умовною залежністю: its
відповідна одиниця буде завантажена тоді і тільки тоді, коли цей символ дійсно є іншим
розшук; інакше буде використано значення за замовчуванням.

?ЗРОБИТИ:таб команда
Після початкових рядків залежностей може бути один або кілька командних рядків. Ті
команди будуть виконуватися, коли пристрій хоче їх завантажити Конфігурувати, Побачити
параграф про команди make для отримання додаткової інформації. Зауважимо, що провідний таб
символ обов'язковий перед команда.

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

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

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

?S:символ_ім'я [(застарілий символ список)]:
Вводить символ оболонки. У цьому першому рядку іменується символ, за яким необов’язково слідує a
список, укладений між дужками та даючи застарілий еквівалент. Ті застарілі
символи будуть переназначені на нові символ_ім'я якщо -o надається варіант
metaconfig.

?S:будь-який Текст, та цінності глосарій
В основному коментар, що описує символ оболонки, який буде витягнутий makegloss
у файл глосарію.

?S:. Закриває коментар до символу оболонки.

?C:символ_ім'я [~ псевдонім] [(застарілий символ список)]:
Вводить новий символ C. The псевдонім Ім'я - це ім'я, під яким буде використовуватися символ C
бути контрольованим, тобто якщо псевдонім шуканий символ, то цей символ C буде записано
в config_h.SH файл. Зазвичай псевдонім просто '%<' (означає назву пристрою)
і є також ?W: лінія, що відображає символ C на псевдонім. Також відповідні частини
рядків ?H: явно захищено умовою '?%<'. Дивіться символ
абзац псевдонімів для більш детальної інформації. Залишок рядка є необов'язковим
застарілий символ список, де перелічено старі еквіваленти для нового символ_ім'я.

?C:будь-який Текст, та цінності глосарій та config_h.SH
В основному коментар, що описує символ C, який буде витягнутий за допомогою makegloss
у файл глосарію та за metaconfig в config_h.SH файл, якщо символ є
бажаний (або якщо його псевдонім потрібен, коли використовується псевдонім символів).

?C:. Закриває коментар до символу C.

?H:?символ:config_h.SH матеріал
Це загальний запит на включення до config_h.SH. Рядок пишеться тільки тоді, коли
охорона символ дійсно розшукується. Ця загальна форма потрібна, коли символ C
був використаний псевдонім. В іншому випадку, якщо ви використовуєте одну з інших «стандартних» форм,
охорона здійснюється автоматично metaconfig себе.

?H:#$d_var VAR "$ вар"
Умовно визначає VAR Символ у $ вар коли встановлено на 'визначати'. Має на увазі а
'?VAR:' охоронний стан, і metaconfig автоматично посилається VAR на дві його оболонки
змінні залежності (тобто обидві $d_var та $ вар буде позначено як хотів if VAR is
використовується в джерелах C).

?H:#define VAR [необов'язковий текст]
Завжди визначає VAR Символ C до деякого значення. Має на увазі '?VAR:' охоронний стан.
Автоматична залежність оболонки створюється до самого пристрою.

?H:#define VAR(x,y,z) $ вар
Завжди визначає макрос VAR бути значенням $ вар змінний. Це залежить від
одиниця для забезпечення $ вар має розумне значення. Автоматична залежність між C
макрос VAR і змінна оболонки встановлюється, і весь рядок охороняється an
неявний '?VAR:'.

?H:#$d_var VAR
Умовно визначає VAR if $d_var встановлено на 'визначати'. Має на увазі '?VAR:' охорона
хвороба. Створюється автоматична залежність оболонки $d_war.

?H:#define VAR "$ вар"
Призначає налаштоване значення для VAR Символ. Має на увазі '?VAR:' охоронний стан.
Для зв’язку створюється автоматична залежність оболонки VAR та $ вар.

?H:. Закриває config_h.SH запити на включення.

?М:C символ: C залежно
Вводить магічне визначення щодо символу C, for confmagic.h, і визначає
охоронний символ для решти ?M: визначення. Ця лінія мовчки має на увазі
'?W:%<:C символ', тобто пристрій буде завантажено в Configure, якщо з'явиться символ C
у джерелах C, незалежно від того, використовується магія чи ні. Залежності C активовано
коли використовується магія, щоб нав’язати їх визначення config_h.SH. Однак якщо
магія є НЕ використовується, але символ C з’являється у джерелі без необхідного C
залежностей, ви будете попереджені щоразу, коли буде створено файл Wanted, оскільки це може бути
проблема портативності (а також тому, що пристрій беззастережно завантажено в
Налаштувати кожен раз, коли використовується символ C, незалежно від інших рядків ?C: з
одиниця).

?М:cpp деф
Визначає магічне відображення cpp, яке буде введено в confmagic.h, коли це стосується
використовується символ. Існує неявний '?sym' охороняє де sym це назва символу
визначається провідною ?M: лінією.

?М:. Закриває confmagic.h запит на включення.

?W:оболонка символ список:C символ список
Пов’язує долю символів оболонки з долю символів C: якщо будь-який із символів C
перераховані символи потрібні, тоді всі символи оболонки позначаються як потрібні. Корисно для
примусове включення одиниці (список символів оболонки встановлено на '%<'), коли присутність деякого C
символ виявлено. Список символів оболонки можна залишити порожнім, щоб отримати вигоду збоку
ефект розташування символу C у вбудованому препроцесорі (символ є певний
для цього препроцесора, якщо він розташований у вихідному коді). Шукати візерунки з пробілом
у них вам потрібно вводити символи C у прості лапки, як у 'struct
часовий пояс'.

?V:тільки для читання Символи:читати писати Символи
Це metalint hint і має використовуватися лише в спеціальних підрозділах, які експортують деяку оболонку
змінні. Змінні перед середнім «:» експортуються лише для читання (змінюючи їх
видасть попередження), тоді як інші символи можна вільно читати та змінювати.

?F:файли створений
Ця лінія служить двом цілям: це a metalint підказку, а також заповнювач для
майбутнє jmake використовувати. Він повинен перерахувати три види файлів: тимчасовий, який є
створені для тесту, а приватні UU створені в каталозі UU на потім
перегляд, а загальнодоступні, залишені в кореневому каталозі пакета. Тимчасовий
файли повинні бути перераховані з попереднім символом '!' символ (що означає «ні! вони не використовуються повторно
пізніше!"), приватним UU-файлам має передувати './' (що означає: використовувати їх, скажімо
./файл, А не тільки файл), а загальнодоступні мають називатися як є.

?T:оболонка тимчасові
Інший metalint підказка. У цьому рядку перелічено всі змінні оболонки, які використовуються як тимчасові
в секції оболонки цього блоку.

?D:символ='значення'
Значення ініціалізації для символів, що використовуються як умовні залежності. Якщо немає ?D: рядок
знайдено, то замість нього використовується значення null. The metalint програма попередить вас, якщо a
символ використовується принаймні один раз як умовна залежність і не має належного
?D: ініціалізація. Це гарна практика додавати ці рядки навіть для нуля
ініціалізації, оскільки вона підкреслює, можливо, необов'язкову природу символу.

?О:будь-який повідомлення ви хотіти
Ця директива вказує на те, що цей блок застарів у цілому. При будь-якому використанні
з його символів (або непряме використання через залежності), повідомлення виводиться на
екран (на stderr). Ви можете помістити одну або кілька рядків, і в цьому випадку буде кожен рядок
бути надрукований, по порядку.

?LINT:metalint підказки
Див metalint сторінку посібника для пояснення окремих підказок, які можуть бути
використаний

?У ЦЬОМУ:ініціалізація код
Код ініціалізації, зазначений у цьому рядку, буде завантажено вгорі
Конфігурувати сценарій за умови, що блок потрібен.

C Symbol Збудження
Іноді на нього не можна покластися metaconfigвласний вибір за замовчуванням для config_h.SH
коментарі та визначення символу C. Ось тут і вступає в гру псевдонім. Так як це швидше
важко пояснити, ми вивчимо приклад, щоб зрозуміти основний механізм.

Модуль d_const.U намагається визначити, чи знає ваш компілятор C про сопзЬ
ключове слово. Якщо це не так, ми хочемо змінити це ключове слово на нульовий рядок, щоб дозволити
компіляція програми. Крім того, ми хочемо автоматично запускати тест, коли сопзЬ слово
використовується.

Ось відповідні частини блоку d_const.U:

?MAKE:d_const: cat cc ccflags Setvar
?MAKE: -pick add $@ %
?S:d_const:
?S: Ця змінна умовно визначає символ HASCONST, який
?S: вказує програмі C, що цей компілятор C знає про
?S: тип const.
?S:.
?C:HASCONST ~ %<:
?C: Цей символ, якщо визначено, вказує на те, що компілятор C знає про
?C: тип const. Насправді не потрібно перевіряти цей символ
?C: у ваших програмах. Просте використання ключового слова const буде
?C: запустити необхідні тести.
?C:.
?H:?%<:#$d_const HASCONST /**/
?H:?%<:#ifndef HASCONST
?H:?%<:#define const
?H:?%<:#endif
?H:.
?W:%<:const
?LINT:встановити d_const
?LINT:відома конст
: перевірити ключове слово const
луна ""
echo 'Перевірка, чи знає ваш компілятор C про "const"...' >&4
/bin/cat >const.c <<'EOCP'
main ()
{
const char *foo;
}
EOCP
якщо $cc -c $ccflags const.c >/dev/null 2>&1 ; тоді
val="$define"
echo «Так, так».
ще
val="$undef"
echo «Ні, це не так».
fi
встановити d_const
eval $setvar

Спочатку ми помічаємо використання рядка ?W:, який, в основному, говорить: «Ця одиниця потрібна, коли
сопзЬ ключове слово використовується у файлі C.". Для умовного перепризначення сопзЬ до нуля
рядок в config.h, я вирішив умовно визначити HASCONST через $d_const.

Однак це створює проблему, оскільки HASCONST символ не буде використовуватися в
джерела, тільки в сопзЬ токен є. І ?H: визначення лінії HASCONST є неявно
охороняється '?HASCONST'. Тому ми повинні додати явне обмеження '?%<', щоб розповісти
metaconfig що ці рядки мають бути включені config_h.SH щоразу, коли символ «%<».
стає в розшук (%< відноситься до назви підрозділу, тут d_const).

Це майже ідеально, тому що лінія ?W: захочеться d_const коли б ні сопзЬ використовується, то
рядки ?H: будуть включені в config_h.SH файл. Однак провідний коментар (?C:
рядків) додається до HASCONST сам також охороняється через HASCONST, тобто має неявний
Обмеження '?HASCONST'. Звідси потреба в псевдонім HASCONST символ до '%<'.

Інша частина блоку (частина оболонки) дійсно проста. Це просто
намагається скомпілювати зразок програми C за допомогою сопзЬ ключове слово. Якщо може, то буде
визначати $d_const чЕРЕЗ $setvar функція (визначається в Сетвар.У одиниця). Дивіться абзац
про спеціальні підрозділи для більш детальної інформації.

зробити Команди
У командному рядку ?MAKE: ви можете написати команду оболонки, яка буде виконуватися як є, або
спеціальний - вибрати команда, яка захоплена metaconfig і проаналізував, щоб побачити, що має бути
зроблено. Провідне "-" призначене лише для запобігання зробити від збою, коли команда повертається
ненульовий статус -- він насправді не потрібен, оскільки ми використовуємо 'зробити -n', щоб вирішити
залежностей, але я раджу вам зберегти його на випадок, якщо він стане обов’язковим у майбутніх версіях.
Синтаксис вибирати команда така:

- вибрати CMD $@ цільовий_файл

де $@ є стандартним макросом у Makefiles, що відповідає поточній цілі (назва
блоку, що будується, з остаточним розширенням .U). The CMD частина є
фактичний metaconfig команда, яку потрібно запустити, і цільовий_файл є ще одним параметром, чий
тлумачення залежить від CMD себе. Він також має остаточне розширення .U
зазвичай посилається на одиничний файл, якщо він не починається з './', і в цьому випадку посилається на один
в metaconfig контрольні файли в '.MT каталог.

Доступні команди:

додати Додає цільовий_файл до Конфігурувати.

add.Config_sh
Заповнює цю частину Конфігурувати виробляючи config.sh файл. Тільки використаний
змінні додаються, умовні (з умовних залежностей).
пропущено.

add.Null Додає розділ, який ініціалізує всі змінні оболонки, що використовуються, до порожнього рядка.

c_h_weed Виробляє config_h.SH файл. Друкуються лише необхідні рядки.

cm_h_weed Виробляє confmagic.h файл. Друкуються лише необхідні рядки. Це
команда доступна лише тоді, коли -M перемикач дається, або коли a confmagic.h файл
вже існує.

close.Config_sh
Додає остаточний символ «EOT» до рядка окремо, щоб закінчити тут документ
побудувати, що виробляє config.sh файлу.

prepend Додає вміст цілі до початку цільовий_файл якщо цей файл не порожній.

weed Додає одиницю до Конфігурувати як додавати команду, але виконайте кілька додаткових тестів
щоб видалити '?символ' і '%символ' рядки з цільовий_файл якщо символ
не є в розшуку або умовно розшукується. Форма "%" використовується лише внутрішньо
metaconfig створюючи власні файли .U у '.MT'каталог.

витерти Те саме, що додавати дійсно, але виконує додаткову макропідстановку. The
доступні макроси описані в Hardwired Макрос пункт.

Як бічна примітка, metaconfig породжує a -конт команда внутрішньо для роботи з умовними
залежності. Ви не повинні використовувати його самостійно, але ви побачите це, якщо скануєте
генерується Makefile в .MT каталог.

Hardwired Макрос
Наступні макроси розпізнаються протирати команди і підміняється до включення в
Конфігурувати:

Базовий номер версії пакета, отриманий від .package.

Поточна дата.


Адреса електронної пошти супроводжувача цього пакета, отримана з вашого
.package.


Назва пакета, похідна від вашого .package файлу.


Рівень патча metaconfig програма (застаріла на користь ).


Рівень ревізії SVN metaconfig програми.

Номер версії metaconfig програми.

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

недавній metaconfig версії розуміють набагато більш загальний синтаксис форми:

<$змінна>

яке замінюється під час генерації Configure на значення змінна взяті з вашого
.package файл. Згодом старий закріплений формат макросу зникне, і <$baserev>
замінить у всіх постачаних одиницях.

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

Ось спеціальні одиниці, про які ви повинні знати, і спосіб їх використання.

Cppsym.U
Цей модуль створює сценарій оболонки під назвою Cppsym, який можна використовувати для визначення
чи визначено будь-який символ у списку наявним у вас препроцесором C чи компілятором C
вказано. Він може визначити статус будь-якого символу, незважаючи на символи в
(список атрибутів) легше визначити.

Цим.У
Це встановлює змінну оболонки $csym, яка використовується внутрішньо Конфігурувати щоб перевірити, чи а
заданий символ C визначено чи ні. Типове використання:

встановити символ результат [-fva] [попередній]
eval $csym

Це встановить результат змінна до "true", якщо функція [-f], змінна [-v] або
масив [-a] визначено, інакше 'false'. Якщо дано попереднє значення і -r
був наданий перемикач Конфігурувати (Див Конфігурувати Опції абзац), то це
значення повторно використовується без допиту.

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

End.U
Скопіювавши цей пристрій у свій приватний U каталогу та додавання залежностей від
?MAKE: рядок, ви можете примусово завантажити певний блок Конфігурувати навіть якщо це не так
інакше хотілося. Деякі підрозділи можуть бути лише примусово Конфігурувати цей шлях.

Fileexp.U
Цей модуль створює сценарій оболонки fileexp який розширить імена файлів, які починаються з
тильди. Типове використання:

exp_name=`./filexp $name`

щоб призначити ім’я розгорнутого файлу в exp_name.

Findhdr.U
Цей агрегат виробляє а findhdr скрипт, який використовується для пошуку заголовних файлів
$usrinc або в інших незнайомих місцях із використанням можливостей cpp. Сценарій дається
включити базову назву файлу, наприклад 'stdio.h' або 'sys/file.h', і він повертає повний шлях до
файл inlcude і нульовий статус, якщо знайдено, або порожній рядок і ненульовий статус
якщо не вдалося знайти файл.

Getfile.U
Цей пристрій створює трохи коду оболонки, який необхідно отримати, щоб отримати файл
назвіть і перевірте осудність. За бажанням виконується розширення ~name.

Щоб використовувати цей пристрій, $rp та $dflt має утримувати питання та відповідь за замовчуванням, які
буде передано як є до myread сценарій (див Myread.U). $fn
змінна керує операцією, і результат повертається $ans.

Щоб знайти файл або каталог, введіть «f» або «d». f~/. Якщо з'являється символ "~", тоді ~name
допускається заміна. Якщо з’являється символ '/', приймаються тільки абсолютні імена шляху
~підміни імені завжди розгортаються перед поверненням. Якщо вказано "+",
перевірки існування пропускаються. Якщо "n" з'являється всередині $fn, тоді користувачеві дозволено
відповісти «нічого».

Зазвичай, якщо ви не запитаєте про переносимість, ~name заміна відбувається за запитом.
Однак іноді ви хочете обійти портативність і змусити його
заміна. Для цього можна використовувати букву «e» (розгорнути).

Якщо використовується спеціальний тип 'l' (locate), то $fn змінна має закінчуватися символом ':',
потім базове ім'я файлу. Якщо відповіддю є каталог, базовим ім’ям файлу буде
додано перед тестуванням існування файлу. Це корисно для запитань у стилі локації
подобається це:

dflt='~news/lib'
: не потрібно вказувати «d» або «f», коли використовується «l».
fn='l~:активний'
rp='Де активний файл?'
. ./getfile
активний = "$ans"

Крім того, літера "p" (шлях) може використовуватися разом із "l", щоб розповісти
getfile що відповідь без символу '/' має бути прийнята, припускаючи, що так
бути на шляху кожного в той момент, коли це значення знадобиться.

Також корисною є можливість вказати список відповідей, які слід прийняти
дослівно, минаючи всі перевірки. Цей список має бути в дужках і елементах
має бути розділений комами, без пробілів. Не забудьте процитувати
отриманий рядок, оскільки дужки мають значення для оболонки. Наприклад:

dflt='/bin/install'
fn='/fe~(install,./install)'
rp='Використовувати яку програму встановлення?'
. ./getfile
встановити = "$ans"

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

Якщо відповідь на запитання «немає», то перевірка існування пропускається і
повертається порожній рядок. Зауважте, що оскільки getfile дзвінки myread внутрішньо, все
функції, доступні з myread подайте заявку тут.

Якщо потрібне повністю розгорнуте значення (наприклад, у Makefile), ви можете використовувати
$ansexp змінна, яка завжди правильно налаштована getfile як розширений
версія $ans. Звичайно, це не буде розширювати ~name, якщо ви не дозволили цього в
перше місце в $fn змінна.

Inhdr.U
Цей агрегат виробляє $inhdr змінна оболонки, яка використовується внутрішньо Конфігурувати перевірити
чи існує набір заголовків чи ні. Типове використання:

встановити заголовок i_header [ header2 i_header2 ... ]
eval $inhdr

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

Inlibc.U
Цей агрегат виробляє $inlibc змінна оболонки, яка використовується внутрішньо Конфігурувати перевірити
чи визначена дана функція C чи ні. Типове використання:

встановити функцію d_func
eval $inlibc

Це надрукує повідомлення про те, чи була функція знайдена чи ні та встановлена
$d_func відповідно. Всередині він використовував $csym рутина.

Loc.U
Цей важливий блок створює сценарій оболонки loc які можна використати, щоб дізнатися, де
у списку каталогів знаходиться даний файл. Перший аргумент визначає файл до
, другий аргумент – це те, що буде повернуто, якщо пошук не вдасться, і
Аргументи reamining — це список каталогів, де потрібно шукати файл. Для
примірник:

dflt=`./loc sendmail.cf X / Usr / Бібліотека /var/lib/sendmail / lib`

встановили б $dflt до X якщо ні sendmail.cf файл знайдено в перелічених каталогах,
або щось подібне /usr/lib/sendmail.cf на деяких системах. Дивись також Getfile.U.

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

MailList.U
Щоб зробити, цей пристрій потрібно включити в лінію ?MAKE: вашого власного приватного End.U
це в Конфігурувати. Він пропонує користувачеві підписатися або скасувати підписку на список розсилки
де відбувається обговорення пакету. Треба бігти packinit
і дайте відповіді на запитання, пов’язані зі списком розсилки, щоб налаштувати правильні змінні у вашому
.package до того, як цей блок почне працювати.

Миинит.У
Скопіюйте цей пристрій у свій приватний U каталог, щоб додати власні значення за замовчуванням до деяких
внутрішні змінні. Цей блок завантажено в Конфігурувати адже за замовчуванням
ініціалізації виконано.

Myread.U
Цей агрегат виробляє myread сценарій оболонки, який необхідно отримати, щоб виконати а
читати. Він дозволяє екранувати оболонку, призначати за замовчуванням і оцінювати параметри, як
задокументовано в підрозділі Instruct.U. Він також дозволяє динамічне налаштування -d варіант
який буде використовуватися для виконання сценарію, що залишився.

Щоб використовувати цей пристрій, $rp має тримати питання і $dflt має містити значення за замовчуванням
відповісти. Питання буде надруковано самим скриптом, а результат повернеться
в $ans змінна.

Ось типове використання:

dflt='y'
rp='Запитання?'
. ./myread
value="$ans"

Для отримання додаткової інформації дивіться сам пристрій.

Oldconfig.U
Цей блок має бути частиною вашої залежності ?MAKE:, коли деякі з ваших блоків намагаються
щоб повторно використовувати старе значення символу. Цей блок відповідає за отримання старих відповідей
від config.sh або надання корисних підказок під час роботи на певній платформі для
перший раз. Див Конфігурувати Поради параграф для отримання додаткової інформації про підказки.

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

Вам потрібно зателефонувати комплект перед видачею евал on префікс $, Такі як:

встановити dflt var [dir]
eval префікс $

який би встановив $dflt до $ вар or $prefix/dir залежно від того, чи залишився префікс
те саме чи ні. Якщо реж - це рядок ніхто, значення одного пробілу в $dflt зберігається як-
є, навіть коли префікс змінюється. Якщо реж опускається, то $dflt встановлено порожнім
рядок, якщо префікс змінився, на $ вар інакше.

Префікс.У
Намір цього блоку подібний до Prefixit.U, тобто він допомагає виправити
рядок за замовчуванням для внесення змін у префікс. Однак змінна оболонки $prefixup,
під час оцінки відновить лише розширення ~назви, якщо префікс використовує такий вихід
механізм. Використовуйте його як:

встановити dflt
eval $prefixup

перед запитом через getfile наприклад. Якщо префікс не використовує ~name
розширення, то вищезазначене буде заборонено y змінна, природно.

Typedef.U
Цей агрегат виробляє $typedef змінна оболонки, яка використовується внутрішньо Конфігурувати перевірити
чи існує typedef чи ні. Типове використання:

встановити typedef val_t за замовчуванням [ включає ]
eval $typedef

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

Unix.U
Метою цього блоку є визначення деяких з найпоширеніших UNIX-ізмів за допомогою змінних
які можна змінити з командного рядка або за допомогою відповідних файлів підказок. Зокрема,
$_exe, $_o та $_a встановлені. Усі одиниці повинні посилатися $_o а не до .o безпосередньо.
'.' є частиною цих змінних.

Сетвар.У
Цей блок створює змінну, яка використовується внутрішньо Конфігурувати встановити a
визначати/undef значення для заданого символу, видає попередження, коли він раптово змінюється
від попереднього значення. Наприклад:

val="$define"
встановити d_variable
eval $setvar

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

Вау
Цей агрегат виробляє whoa скрипт, який видає попередження, коли значення у змінному
чиє ім'я $ вар не збігається зі своєю старою попередньою вартістю $був. На
повернути, $td та $tu утримувати належне значення визначати or undef змінна. Побачити
приклади в Inlibc.U.

Вбудований Попередній процесор
Кожна одиниця, яка буде включена Конфігурувати виконується через вбудований препроцесор. Попередньо
Оператори процесора вводяться символом "@" ("#" - це коментар оболонки
характер). Він функціонує просто як препроцесор C, але допускає оболонки та perl
втечі. Ось доступні функції:

@якщо вираз
If вираз true, продовжуйте завантажувати код до @end, @elsif або @else.

@elsif вираз
Альтернативний вибір. Якщо вираз правда, продовжуйте завантажувати код до @end,
інший @elsif або @else.

@else Код за замовчуванням, який завантажується, якщо @if вираз було помилковим і жодним із них
необов’язковий збіг @elsif. Завантажити до @end.

@end Закрити оператор умовного завантаження, відкритий @if.

@define символ
Повідомляє про це препроцесору символ визначається відтепер.

Умовний вираз може включати назви символів (значення є істинним, якщо символ потрібен або
визначено через @define або команди shell/perl. Ці атоми можна об’єднати за допомогою
традиційні логічні оператори '!' для заперечення, '&&' для логічного і, і '||' для логічного
або.

Текст, укладений в одинарні дужки, є тестом оболонки, а текст між подвійними дужками — це тест
тест perl. А саме вирази:

{ оболонка текст }
{{ Perl текст }}

перекладаються на:

if оболонка текст >>/dev/null 2>&1; потім вихід 0; інакше вихід 1; fi
Якщо (Perl текст) {вихід 0;} else {вихід 1;}

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

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

@if {test -d ../hints}

та Конфігурувати міститиме код, що залежить від підказок, лише якщо є a підказки каталозі в
каталог верхнього рівня пакета. Зауважте, що тести виконуються з '.MT' каталог,
отже необхідний '../' в тесті.

Попередній процесор також можна використовувати, щоб уникнути введення марного коду, коли символ не є
визначений. Таким чином можна захистити одиниці, що визначають більше одного символу (оскільки блок
завантажується як єдине ціле), збираючи залежний від символів код у парі @if/@end. Для
примірник:

@if I_TIME || I_SYS_TIME || I_SYS_TIME_KERNEL
need_time_h='true'
@інше
need_time_h='false'
@end

перевірить, чи використовує вихідний код один із трьох контрольних символів
час.h or sys/time.h включення та визначте символ оболонки відповідно. Це дає
Конфігурувати зворотній зв’язок щодо того, що потрібно джерелам, і уникнути недоліків виправлень
заморожені одиниці.

За допомогою рядків '?W:' ви можете отримати цікаві комбінації. Наприклад, i_time.U блок
необхідно знати, чи використовують джерела C структура часовий пояс типу. тому
лінія:

?W::часовий пояс

використовується для його побічного ефекту визначення символу часовий пояс для попереднього процесора. The
код одиниці може сказати:

@if часовий пояс
для s_timezone в '-DS_TIMEZONE' ''; робити
@інше
s_timezone=''
@end

... код за допомогою s_timezone ...

@if часовий пояс
зроблений
@end

і мати додатковий цикл, пробуючи два послідовних значення для s_timezone змінна, але тільки
якщо це необхідно.

Застарілий Символи
Застарілі символи збережено, щоб полегшити перехід зі старими metaconfig одиниць. Хіба що
-o перемикач передається до metaconfig вони будуть ігноровані. Однак, an Застарілий файл буде
бути згенеровано, повідомляючи вам, які файли використовують ці застарілі символи і які
це нові символи, які будуть використані.

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

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

У будь-якому випадку, для всіх тих крихітних проблем, які занадто специфічні для системи, metaconfig
забезпечує підтримку файлів підказок. Щоб використовувати його, потрібно створити a підказки каталозі в
каталог верхнього рівня пакета і мати його під час запуску metaconfig. Це завантажить
частина, пов’язана з підказкою Oldconfig.U.

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

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

Наприклад, відомо, що системи SGI зламалися vfork() системний виклик, починаючи з цього
написання. І відповідне ім'я файлу підказки sgi.sh. Тому все, що вам потрібно зробити, це створити
a підказки/sgi.sh файл, в якому ви пишете:

d_vfork="$define"

який завжди буде переназначатися vfork on вилка (Див. d_vfork.U). Під час роботи на системах SGI для
перший раз, Конфігурувати виявить, що є підказки/sgi.sh файл, і ми на
машина IRIX (ім'я ядра часто /irix), тому вона запропонує sgi як
можлива підказка. Якщо користувач приймає це, і оскільки $d_vfork значення змінюється за допомогою
$setvar дзвонити, а ого! буде випущено, щоб попередити, що ми збираємося змінити значення
обчислено за Конфігурувати.

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

Переважаючий Вибори
Якщо ви створите файл config.over файл у каталозі верхнього рівня, Конфігурувати запитає вас, якщо ви
хочете завантажити його, щоб замінити значення за замовчуванням. Це робиться перед створенням
config.sh файл, тож це дає вам можливість виправити значення, що зберігаються в ньому.

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

Конфігурувати Опції
Команда Конфігурувати скрипт може бути викликаний з деякими параметрами, зазначеними в командному рядку, to
трохи змінити його поведінку. Ось дозволені варіанти:

-d Використовуйте значення за замовчуванням для всіх відповідей.

-e Продовжуйте без сумнівів минуле виробництво config.sh.

-f файл Використовуйте вказаний файл як конфігурацію за замовчуванням. Якщо цей перемикач не використовується,
конфігурація взята з config.sh, якщо присутній.

-h Роздрукуйте довідкове повідомлення та вийдіть.

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

-s Режим тиші. Лише рядки, надруковані на файловому дескрипторе №4, відображатимуться на
екран (це важливі повідомлення). Повністю вимкнути неможливо
будь-який вихід, але ви можете використовувати 'Конфігурувати -дери > / dev / null 2> & 1' мати повну
пакетний запуск без виведення даних і взаємодії з користувачем.

-D символ=значення
Попередньо визначає символ нести зазначене значення. Також можна використовувати '-D
символ', який використовуватиме значення за замовчуванням 'define'.

-E Зупиніться в кінці запитань щодо конфігурації, створивши a
config.sh. Це не дасть жодного 'зробити залежати' або .SH вилучення файлів.

-K Обізнаний користувач. Коли ви використовуєте цю опцію, ви знаєте, що робите і
тому config.sh файл завжди буде оброблятися так, ніби це було призначено
повторно використаний, навіть якщо він міг бути згенерований на чужорідній системі. Це також
запобігає переривання вагітності, коли Конфігурувати виявляє непридатний компілятор C або неправильний набір
прапорів C. Подальші ярлики також можуть бути ввімкнені за допомогою цієї опції в
майбутнє. Цей параметр задокументовано в Конфігурувати повідомлення про використання, щоб нагадати нам
про його існування, але наведений опис, сподіваємося, буде досить загадковим.
:-)

-O Дозволити значення, зазначені через a -D or -U щоб змінити налаштування з будь-якого завантаженого
файл конфігурації. Це не поведінка за замовчуванням, оскільки перевизначення буде
не поширюватися на змінні, похідні від тих, які ви зараз змінюєте.
Природно, без -O, налаштування виконується лише тоді, коли немає файлу конфігурації
завантажено, що безпечно, оскільки похідні змінні ще не обчислені...

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

-U символ=
Попередньо встановлені символ мати порожнє значення. Також можна використовувати '-U символ'
який встановить символ до 'undef'.

-V Надрукуйте номер версії metaconfig що породило це Конфігурувати сценарій
і вийти.

Робота Навколишнє середовище
Після початку, Конфігурувати створює локальний UU каталог і запускається звідти. Довідник
видаляється, коли Configure закінчується, але це означає, що ви повинні запустити сценарій з місця, де
ви можете писати, тобто не з файлової системи, доступної лише для читання.

Можна бігати Конфігурувати але віддалено, як у:

../package/Configure

щоб налаштувати джерела, яких немає локально. Всі згенеровані файли будуть вставлені
каталог, з якого ви запускаєте скрипт. Ця магія зроблена завдяки src.U
блок, який налаштовує $src та $rsrc змінні, які вказують на джерела пакета. Це
шлях повний або відносний, залежно від того, чи Конфігурувати був викликаний за допомогою повного або
відносний шлях.

Зсередини UU підкаталог, ви можете використовувати $rsrc для доступу до вихідних файлів (одиниць
посилаючись на вихідні файли, підказки посилань завжди повинні використовувати цей механізм і не припускати
файл знаходиться в батьківському каталозі). Усі Make-файли повинні використовувати змінну $src
як вказівник на джерела зверху каталогу збірки (де Конфігурувати запущено),
безпосередньо або через налаштування VPATH.

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

використання магія Перевизначення
Використовуючи -M перемикання, деякі магічні перепризначення можуть мати місце в межах a confmagic.h
файл. Цей файл потрібно включити після config.h, звичайно, але й зрештою
інші необхідні файли включення. а саме:

#include "config.h"
...
... інший включення ...
...
#include "confmagic.h"

Зазвичай confmagic.h спробує перепризначити bcopy() on memcpy() якщо ні bcopy() is
доступні локально або трансформуйте vfork в вилка коли це необхідно, що робить його марним
турбуватися про HAS_VFORK символ.

Ця магія конфігурації задокументована у файлі глосарію.

Блок шаблони
Існує набір шаблонів одиниць у metaconfig вихідний каталог, який призначений для
використовуватися (ще не написаною) програмою для швидкого виробництва нових одиниць для різних видів
ситуації. Немає документації для цього незавершеного проекту, але я думав згадати про нього
на сторінці посібника, якщо ви хочете зробити це самостійно, а потім зробити це...

AUTHORS

Ларрі Уолл[захищено електронною поштою]> для версії 2.0.
Харлан Стенн[захищено електронною поштою]> для важливих розширень одиниць.
Рафаель Манфреді[захищено електронною поштою]>.
Багато інших дописувачів для metaconfig одиниць. Перегляньте кредитний файл для списку.

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