Существует множество терминов, которые часто используются при обсуждении утилит для разработки программ. Большинство общих терминов используется для обозначения множества понятий с различными значениями, что вызывает путаницу. Обычно мы угадываем их значение из контекста и чаще всего неправильно.
В этом документе используется сравнительно мало терминов с целью определения понятий настолько точно, насколько это возможно для передачи назначений и условий использования этих утилит.
Программы работают на машинах. Они почти всегда записаны в исходных текстах и строятся из них. Компиляция - это процесс, которым часто, но не всегда создаются программы.
Здесь слово "основная" относится к среде, в которой будут откомпилированы эти исходные тексты. Имя основной среды не имеет отношения к имени Вашей главной машины, например, ucbvax, prep.ai.mit.edu или att.com. Вместо них оно относится к sun4 или dec3100.
Забудем на минуту, что в нашем каталоге исходных текстов находится исходный текст для среды разработки программ. Предположим, что это исходный текст для более простой прикладной программы, скажем, калькулятора. Исходные тексты, которые можно компилировать в различных средах, обычно требуют установок для каждой среды. Мы называем этот процесс конфигурацией. Это конфигурация исходного текста для среды.
Например, если нам требуется конфигурация нашего воображаемого калькулятора для компилирования на SparcStation, мы должны конфигурировать для среды sun4. Т.е. с нашей системой конфигурации:
cd desk-calculator ; ./configure sun4
Основная среда не обязательно привязана к той машине, на которой были откомпилированы утилиты; можно имитировать основную среду sun3 на sun4. Если мы хотим использовать кросс-компилятор на sun4 для компилирования программ, предназначенных для работы на sun3, мы сконфигурируем исходный текст для sun3:
cd desk-calculator ; ./configure sun3
Основная среда не имеет отношения к машине, на которой будет работать созданная программа. На sun4 можно обеспечить эмуляцию среды sun3, и программы, скомпилированные на sun3, будут работать на sun4. Эта практика часто используется в индивидуальных программах для компенсации отличий различных архитектур и операционных систем. Например, некоторые операционные системы не обеспечивают функцию bcopy, и она эмулируется, используя функцию memcpy.
Основная среда - это просто среда, в которой будет скомпилирована эта программа.
Многие программы имеют опции времени компиляции. Это возможности программы, которые могут быть встроены в программу и зависят от выбора человека, проводящего компиляцию. Мы определяем это как опции конфигурации. Например, наш калькулятор возможно скомпилировать в программу, которая использует инфиксную или постфиксную запись как параметры конфигурации. Чтобы выбрать инфиксную запись при работе на sun3:
./configure sun3 --enable-notaion=infix
./configure sun4 --enable-notaion=postfix
Следующие команды:
mkdir ../objdir.sun4
(cd ../objdir.sun4 ; ../configure sun4 --enable-notation=postfix --srcdir=../ scr)
mkdir ../objdir.sun3
(cd ../objdir.sun3 ; ../configure sun3 --enable-notation=infix --srcdir=../ scr)
Основываясь на этих примерах, будем предполагать, что нам необходимо построить утилиты на каком-то месте, и не использовать параметр --srcdir, но будем помнить о нем.
Для инсталяции программы конфигурирующей системе необходимо знать, где Вы хотите ее установить. По умолчанию она будет храниться в '/usr/local'. Мы ссылаемся на это расположение с помощью '$(prefix)'. Все запускаемые пользовательские программы будут установлены в '$(prefix)/bin'. Все другие программы и файлы будут установлены в подкаталоге '$(prefix)/lib'.
Вы можете сменить '$(prefix)' только как параметр конфигурации:
./configure sun4 --enable-notation=postfix --prefix=/local
make install
make clean
Зная эти понятия, мы можем отбросить пример с калькулятором и перейти к прикладным программам в этих каталогах, а точнее, к исходному тексту для среды разработки программ.
GNU утилиты разработки могут быть скомпилированы в различных основных средах. При этом их нужно сконфигурировать, например, как в следующем примере:
./configure sun4 --prefix=/local
./configure sun3 --prefix=/local
При компиляции в подходящей среде разработки мы получим родные утилиты. Мы объясним термин "родной" позже.
GNU утилиты в ряде основных сред можно не только скомпилировать, но и сконфигурировать для получения различных сред разработки в каждой их этих основных сред. Мы определяем особую созданную среду разработки как целевую, т.е. слово "целевая" относится к среде разработки, получаемой компиляцией этих исходных текстов и инсталлированием получаемых программ.
Для GNU утилит целевая среда - то же самое, что и основная. Т.е. среда разработки будет совместима со средой, в которой утилиты компилировались.
В предыдущем примере мы создали две конфигурации: для sun4 и sun3. Первая конфигурация предполагает компилирование на sun4 для создания среды разработки sun4. Необязательно компилировать на sun4, если среда разработки sun4 доступна еще где-нибудь. Также, если эта среда позволяет производить запускаемые файлы, не предназначенные для sun4, то среда разработки, скомпилированная на этой конфигурации sun4, может работать и не в sun4. С точки зрения системы конфигурации и исходных текстов GNU утилит это не важно. А важно то, что они будут откомпилированы в среде sun4.
Далее, вторая конфигурация, представленная выше, предназначена для компилирования в среде разработки sun3 и для создания среды разработки sun3.
Среда разработки зависит от опции конфигурации, например от '$(prefix)'.
./configure sun4 --prefix=/local --target=sun3
./configure sun3 --prefix=/local --target=sun4
В отличие от предыдущего примера, первая конфигурация создаст среду sun3, подходящую для построения второй конфигурации. Подобно этому, вторая конфигурация создаст среду sun4, подходящую для построения первой конфигурации.
Среда разработки, использующая эти конфигурации, определяет машину, на которой будет работать получаемая среда разработки.
Предположим на минуту, что у Вас есть sun4, и что вместе с Вашим sun4 Вы получили среду разработки. Эта среда предназначена для работы на Вашем sun4 и создания программ, работающих на sun4. Например, Вы можете использовать эту среду для построения нашей программы-примера, калькулятора.
Полученную программу калькулятора мы определим как родную. Среда разработки сама по себе состоит из родных программ, которые, работая, порождают другие родные программы. Все другие программы относятся к чужим. Программы предназначенные для других машин - чужие.
Этот, гораздо более заурядный, тип среды разработки мы называем родным, т.е. родная среда разработки, работая на некоторой машине, создает родные программы для этой некоторой машины. Процесс создания родной среды разработки для создания родных программ называется родным построением.
Команда:
./configure sun4
Среда разработки на sun4, получаемая вместе с машиной, будет одной из этих сред. Использование ее для создание GNU утилит - довольно обычное явление, и получаемая среда достаточно популярна.
Команда:
make all
Использование среды разработки для создания среды разработки называется раскруткой. Реализацию GNU утилит разработки можно назвать самораскруткой. Это очень мощный метод, к которому мы вернемся позже. Теперь предположим, что мы используем родную среду Вашего sun4 для раскрутки и назовем получаемую среду разработки stage1.
Зачем суетиться? Большинство людей считают, что GNU среда разработки создает программы, которые работают быстрее и занимают меньше места, чем те, что создает родная среда, полученная вместе с машиной. Некоторые люди получают машину вообще без среды разработки, а некоторым просто удобнее в GNU среде.
Кстати об этом, если GNU утилиты создают программы лучше, то может быть, следует строить ими сами GNU утилиты? Предположим, что Вы так и сделали и назвали полученную среду stage2.
Итак, Вы построили среду stage1 и использовали stage1 для построения новой, более быстрой и меньшей по размерам среды stage2, но Вы не запускали ни одной программы, созданной GNU утилитами. Вы еще не знаете, будут ли они работать? Есть ли у Вас какие-нибудь программы, созданные GNU утилитами? Есть - stage2. Что эта программа делает? Она создает программы. Хорошо, есть ли у Вас исходный текст, который необходимо скомпилировать в программу? Да, есть - сами GNU утилиты. Очевидно, что если Вы снова используете stage2 для построения GNU утилит, то получатся утилиты, идентичные stage2. Допустим, что Вы создали их и назвали stage3.
То, что Вы только что проделали, называется трехступенчатая раскрутка. Теперь у Вас есть быстрая, маленькая и проверенная среда разработки.
Команда:
make bootstrap
Команда:
make install
Любую неродную среду разработки мы относим к кросс-средам. Существует множество различных кросс-сред разработки, но большинство из них попадает в три основных категории.
Первая категория кросс-сред разработки называется средой эмуляции. Существует два основных типа сред эмуляции, но оба типа приводят к программам, которые работают в родной основной среде.
Первый тип - это эмуляция архитектуры. Это форма кросс-среды разработки, состоящая из родных утилит, которые при работе в родной основной среде разработки способны интерпретировать и выполнять программы, предназначеные для других машин. Этот прием обычно используется, если другие машины: очень дороги, очень медленны, слишком быстры, либо недоступны, например, потому, что еще не созданы. Родная интерпретирующая программа называется эмулятором архитектуры.
GNU утилиты обычно не содержат эмуляторов архитектуры. Но возможна такая конфигурация GNU утилит для создания простой кросс-среды, в которой есть эти эмуляторы. Подробнее об этом позже.
Второй тип эмуляции - это когда исходный текст, предназначенный для других сред разработки, компилируется в программу, предназначенную для родной основной среды. Концепции операционных систем схожи, и возможна начальная отладка программы на машине, отличной от целевой.
Команда:
./configure sun4 --target=a29k
Ранее Вы видели, как сконфигурировать утилиты для создания родной среды разработки, т.е. среды, которая работает на Вашем sun4 и создает программы для работы на sun4. Пусть Вы использовали stage3 для создания простой среды разработки и назвали ее gcc-a29k. Помните, что это родной продукт, так как gcc-a29k - это набор родных программ, предназначенных для работы на sun4, потому что stage3 создает программы для sun4. Среда разработки gcc-a29k представляет собой среду разработки для архитектуры a29k и создает программы, предназначенные для работы на a29k. Но помните, что gcc-a29k работает на Вашем sun4, программы же, созданные средой gcc-a29k будут работать на Вашем sun4 только с помощью подходящего эмулятора архитектуры.
Построение gcc-a29k - это, в сущности, раскрутка, только немного другого рода. Мы называем gcc-a29k простой кросс-средой, а использование ее для создания программ, предназначенных для a29k, называется кросс-генерация. Простая кросс-среда - это вторая категория кросс-сред разрабоки.
Команда:
./configure a29k --target=a29k
Если вы следуете этому общему обзору, то Вы уже создали среду, предназначенную для a29k, называемую gcc-a29k. Предположим, что Вы использовали gcc-a29k для построения конфигурации, описанной выше.
Gcc-a29k создает программы, работающие на a29k, так что новая среда будет предназначена для работы на a29k. Т.е. этот новый gcc состоит из утилит, чужих для Вашего sun4. Они не смогут работать на Вашем sun4.
Процесс компилирования этой конфигурации - это другая раскрутка. Такая раскрутка является также и кросс-генерацией в коды a29k. Поэтому мы иногда называем ее кросс-генерацией на a29k. Эта новая среда разработки - не совсем кросс-среда. Она предназначена для работы на a29k и создания программ для a29k. И запомните, что, по определению, этот факт делает ее родным компилятором для a29k. "Кросс-генерация на" не является типом кросс-среды разработки, хотя ее часто путают с этим типом. "Кросс-генерация на" - это действительно кросс-генерация, но в результате мы получаем родную среду разработки.
Мы не могли скомпилировать эту конфигурацию с помощью stage3, так как stage3 не обеспечивает среду, предназначенную для a29k. Вместо нее stage3 обеспечивает среду sun4.
Если у Вас есть под рукой a29k, Вы можете использовать эту новую среду разработки для трехступенчатой раскрутки всех утилит на a29k. Этот процесс напоминает, как мы строили родную среду разработки sun4, так как мы строим другую родную среду разработки, среду для a29k.
Итак, мы видим, что наш исходный текст среды разработки необходимо сконфигурировать для определенной основной среды и определенной целевой среды. Также мы видим, что получаемая среда разработки зависит от среды разработки, используемой в процессе компиляции.
Получаемая среда разработки будет родной, если идентичны: основная среда в конфигурации, целевая среда в конфигурации, среда, представляемая средой разработки, используемой для компиляции и машина, на которой наша среда разработки будет работать.
Если совпадают все среды кроме основной среды, то мы можем предположить, что среда разработки используемая для компиляции есть некоторая форма библиотеки эмуляции.
Если не совпадает только целевая среда, то полученная среда разработки будет простой кросс-средой разработки.
Если же исключение составляет основная среда с которой работает среда, используемая для компиляции, то мы имеем процесс "кросс-генерации на", и получаемая среда будет родной для какой-то другой машины.
Большинство других вариантов возможно в некоторой форме, но только следующий представляет интерес.
Команда:
./configure a29k --target=sun3
Если Вы следуете руководству, то у Вас уже есть две среды разработки, предназначенных для a29k: родная среда разработки, которая работает на a29k и простая кросс-среда разработки, которая работает на Вашем sun4. Если Вы используете родную среду разработки для a29k на a29k, то Вы сделаете то, что мы уже делали ранее, а точнее простой кросс-компилятор из a29k в sun3. Предположим, что вместо этого вы используете gcc-a29k, простую кросс-среду, которая работает на sun4, но создает программы для a29k.
Полученная среда разработки будет работать на a29k, так как gcc-a29k создает программы для a29k. Это новая среда будет создавать программы предназначенные для sun3, согласно конфигурации. Т.е. полученная среда разработки - это простой кросс-компилятор.
Для этого процесса нет общего названия, так как можно сконфигурировать очень много сред разработки. Для удобства назовем этот процесс канадская кросс-генерация. Кросс-генерация состоит из трех частей, а Канада имеет трехпартийную систему, отсюда Канадская.
Под конфигурированием, мы подразумевали создание ссылок, Makefile, .gdbinit и config.status. Конфигурация всегда производится из каталога исходного текста.
Команда:
./configure <имя>
Команда:
./configure <имя-основной-среды> --target=<имя-целевой-среды>
Конфигурирование делает, в сущности, три вещи: создает соответствующие подкаталоги, строит Makefile и создает ссылки на файлы; основываясь и аппелируя при этом к специфической паре основная+целевая. Также создается файл ".gdbinit", но далеко не всегда.
Makefile создается путем подготовки некоторых определений переменных, в промежуточном файле "Makefile.in" и введением особых фрагментов зависящих от основной и целевой архитектур. Причем переменные зависят от выбора пары основная+целевая и стиля построения, т.е. от того используете ли Вы --scrdir или нет. Специалищации на основную и целевую архитектуру в Makefile может и не быть.
Makefile можно редактировать напрямую, но эти изменения могут быть утеряны. Изменения, которые должны сохраниться для особой основной среды необходимо сделать в главном особом фрагменте Makefile. Т.е. в каталоге './config/mh-<основная среда>', если он существует. Изменения для особой целевой среды следует сделать в целевом особом фрагменте Makefile. Т.е. в каталоге './config/mt-<целевая среда>', если он существует. Изменения для каталога необходимо сделать в "Makefile.in". Чтобы произвести какие-нибудь из этих изменений необходимо использовать либо команду "make Makefile", либо команду "./config.status", либо переконфигурацию.