/sys/doc/ Documentation archive

APE — среда ANSI/POSIX

Говард Трики
howard@plan9.bell-labs.com

Введение

Среда ANSI/POSIX, сокращенно APE, используется при необходимости портирования большого по размеру или часто-обновляемого программного обеспечения в Plan 9 или из нее. APE — это набор заголовков и объектного кода библиотек, построенных на стандарте ANSI C (ANSI X3.159-1989) и стандарте интерфейса операционных систем POSIX (IEEE 1003.1-1990, ISO 9945-1), POSIX часть описывает основные функции операционной системы. Использование APE влечет низкую скорость компиляции и выполнения кода, так что если импорт или экспорт ПО производится довольно редко и скорость имеет значение, то более приемлемым является использование обычной среды компиляции Plan 9. Другой причиной для использования среды Plan 9 (а не APE) является то, что ее организация заголовков более проста для запоминания и использования.

Существует также некоторые аспекты необходимого поведения POSIX, которые невозможно или очень трудно имитировать в Plan 9. Они описаны ниже. Опыт показывает, что имитирование возможно для большинства программ. Более серьезной проблемой является то, что многие программы используют не предусмотренные в стандарте POSIX функции и заголовки. APE содержит расширения POSIX в этом плане. Для того чтобы среда APE подходила для тестирования программ ANSI/POSIX, расширения должны быть явно описаны в разделе #define.

Pcc

Команда pcc работает как внешняя для компиляторов и загрузчиков Plan 9 C. Она запускает препроцессор ANSI C для исходных файлов, используя заголовки APE для определения директив #include <файл>; затем она запускает компилятор Plan 9 C; и наконец, она загружается с APE библиотеками для создания исполняемой программы. Документ «Как использовать компилятор Plan 9 C» (How to Use the Plan 9 C Compiler, /sys/doc/comp.ps) объясняет как переменные окружения используются при компиляции на различных архитектурах. Переменная окружения $objtype управляет тем, какой Plan 9 компилятор и загрузчик используются pcc, также как и размещение файлов заголовков и библиотек. Например, если переменная $objtype имеет значение mips, тогда pcc указывает cpp искать заголовки в каталоге /mips/include/ape, следующим после /sys/include/ape; затем pcc использует vc для создания объектных файлов с расширением .v; и наконец, vl используется для создания исполняемого кода с использованием библиотек из каталога /mips/lib/ape.

Psh и Cc

Команда pcc предназначена для просмотра исходного кода на наличие ANSI/POSIX, но сами программы постраиваются обычным для Plan 9 способом: посредством mk и созданием объектных файлов с именами, заканчивающимися расширением .v, и т.п. Но иногда бывает полезнее использовать программы POSIX make и cc (который создает объектные файлы с именами, заканчивающимися .o, а также автоматически вызывает загрузчик, если опция -c не указана). В таком случае, выполните следующую команду:

Она запускает POSIX оболочку со средой, включающей POSIX команды: ar89, c89, cc, basename, dirname, expr, false, grep, kill, make, rmdir, sed, sh, stty, true, uname, и yacc. Также есть несколько метка-заполнителей для команд, которые не предусмотрены в Plan 9: chown, ln и umask.

Команда cc обладает опциями POSIX c89, определенными в C-Language Development Utilities Option, приложении стандарта POSIX Shell and Utilities. Также существуют несколько нестандартных опций, описанных ниже:

Команда sh является оболочкой pdksh, наиболее распространенной и уступчивой POSIX версией Korn Shell. Реализация Plan 9 не содержит режимов редактирования emacs и vi.

Команда stty эффективна лишь в том случае, если команда ape/ptyfs запущена для вставки псевдо-tty интерфейса между /dev/cons и запущенной командой. Ни одна распространяемая команда не делает этого автоматически.

Символы

Стандарты C и POSIX требуют, чтобы определенные символы описывались в заголовках. Описание (или не описание) зависит от типа самих символов и усмотрения реализации. POSIX описывает макросы (макроопределения), которые также являются символами препроцессора, начинающимися с символа подчеркивания и с далее идущими буквами в верхнем регистре; если программа, описанная в разделе #defines, является макросом, то перед включением каких-либо заголовков она посылает запрос на то, чтобы определенные символы были видимыми в заголовках. Наиболее важным макросом является _POSIX_SOURCE: символы, характерные POSIX, становятся видимыми в соответствующих заголовках. Рассмотрим этот факт на примере: ANSI определяет некоторые имена, которые должны быть описаны, но POSIX, в свою очередь, определяет другие имена, такие как sigset_t, которые не допускаются согласно ANSI. Эта проблема решается созданием дополнительных символов видимыми только когда определен макрос _POSIX_SOURCE.

При экспорте программ он помогает установить, входит ли программа в одну из следующих категорий:

  1. Строго соответствующая программа ANSI C. Ею используются лишь характеристики языка, библиотек и заголовков, соответствующие стандарту C. Она не зависит от неопределенного, неописанного, или зависимого от реализации поведения, и не превышает любой минимальный предел реализации.
  2. Строго соответствующая программа POSIX. Аналогична вышеописанной, только для стандарта POSIX.
  3. Усовершенствованный набор POSIX с расширениями. Каждое расширение выбирается макросом, так что ясно какие расширения здесь используются.

Что касается обезьяны, тьфу, то есть APE, если заголовки всегда включают объявления любых используемых библиотечных функций, то набор макросов, описанный в программе, будет указывать к какой из вышеперечисленных категорий относится программа. Чтобы выполнить это, символы, не соответствующие стандарту C или POSIX не должны описываться в заголовке, а те которые принадлежат стандарту POSIX должны защищаться макросом #ifdef _POSIX_SOURCE. К примеру, определения EDOM, ERANGE, и errno соответствуют стандарту C. Стандарт C допускает больше имен, начинающихся с буквы E, но наш заголовок описывает все макросы, отличные от _POSIX_SOURCE, в этом случае символы, требующиеся POSIX, также определяются. Это значит, что программа, использующая ENAMETOOLONG, не может замаскироваться под строго соответствующую программу ANSI C.

Pcc и cc не могут определять никакие препроцессоры, отличные от 5 встроенных в стандарт ANSI C: __STDC__, __LINE__, __FILE__, __DATE__, и __TIME__ . Любые другие должны определять себе в программе или, используя опцию -D, в командной строке.

Расширения

Операция, осуществляемая вставкой только необходимых имен в заголовки, полезна при экспорте программ, но она несколько мешает при импорте программ. Компромиссом может быть учитывание дополнительных символов в заголовках, дополнительных заголовках, и дополнительных библиотечных функциях, но только под управлением расширенных макросов. Следующие расширения предусмотрены; если они не указаны явно, то дополнительные библиотечные функции предусмотрены в библиотеке APE по умолчанию.

Общие проблемы

Несколько больших систем, включая X11, были удачно портированы в Plan 9 с использованием APE (порт X11 не включается в основной дистрибутив Plan 9, поскольку для его поддержки нужно слишком много работы). Проблемы можно разделить на три основные категории: (1) используются характеристики не ANSI C/POSIX; (2) неадекватное имитирование POSIX функций; и (3) дефекты компилятора/загрузчика. Наибольшее количество проблем возникает в первой категории.

В данный момент POSIX только становится мишенью для программистов. Большая часть существующего кода написана для работы с одной из систем (или с обоими) BSD или System V Unix. Последняя довольно близка к POSIX, но, все-же, есть и некоторые различия. Также множество System V систем импортировали некоторые характеристики BSD, которые не являются частью POSIX. Хорошей стратегией портирования внешних программ является использование макроса CFLAGS=-D_POSIX_SOURCE; если это не работает, попробуйте добавить _D_BSD_EXTENSION а также включите <bsd.h> в исходные файлы. Вот некоторые решения проблем, которые могли остаться:

Неадекватность имитирования POSIX функций в Plan 9. Этот недостаток редко происходит (кроме случаев проблем с link), но, все-же, мы их опишем:

Copyright © 2000 Lucent Technologies Inc. All rights reserved.
Copyright © 2003 Перевод Андрей С. Кухар.