Конфигурирование утилит разработки.: Общий обзор

Вперед Назад Содержание

4. Общий обзор

4.1 Родная среда разработки

Предположим на минуту, что у Вас есть sun4, и что вместе с Вашим sun4 Вы получили среду разработки. Эта среда предназначена для работы на Вашем sun4 и создания программ, работающих на sun4. Например, Вы можете использовать эту среду для построения нашей программы-примера, калькулятора.

Полученную программу калькулятора мы определим как родную. Среда разработки сама по себе состоит из родных программ, которые, работая, порождают другие родные программы. Все другие программы относятся к чужим. Программы предназначенные для других машин - чужие.

Этот, гораздо более заурядный, тип среды разработки мы называем родным, т.е. родная среда разработки, работая на некоторой машине, создает родные программы для этой некоторой машины. Процесс создания родной среды разработки для создания родных программ называется родным построением.

Команда:

 ./configure sun4 
сконфигурирует наш исходник так, что при построении на sun4 со средой разработки, которая создает программы, предназначеные для работы на 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
совершит трехступенчатую раскрутку для всех утилит, и после сравнения stage2 со stage3 сообщит, если они различны.

Команда:

 make install 
инсталлирует среду разработки в каталог, определенный по умолчанию, или в каталог '$(prefix)', если Вы определили альтернативу при конфигурации.

Любую неродную среду разработки мы относим к кросс-средам. Существует множество различных кросс-сред разработки, но большинство из них попадает в три основных категории.

4.2 Среды эмуляции

Первая категория кросс-сред разработки называется средой эмуляции. Существует два основных типа сред эмуляции, но оба типа приводят к программам, которые работают в родной основной среде.

Первый тип - это эмуляция архитектуры. Это форма кросс-среды разработки, состоящая из родных утилит, которые при работе в родной основной среде разработки способны интерпретировать и выполнять программы, предназначеные для других машин. Этот прием обычно используется, если другие машины: очень дороги, очень медленны, слишком быстры, либо недоступны, например, потому, что еще не созданы. Родная интерпретирующая программа называется эмулятором архитектуры.

GNU утилиты обычно не содержат эмуляторов архитектуры. Но возможна такая конфигурация GNU утилит для создания простой кросс-среды, в которой есть эти эмуляторы. Подробнее об этом позже.

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

4.3 Простые кросс-среды

Команда:

 ./configure sun4 --target=a29k 
сконфигурирует утилиты так, что полученная при компилировании в среде разработки среда может быть использована для создания программ, предназначенных для среды разработки a29k. Это не значит, что новая среда разработки будет работать на sun4. Это зависит от среды разработки, использованной для создания этих утилит.

Ранее Вы видели, как сконфигурировать утилиты для создания родной среды разработки, т.е. среды, которая работает на Вашем 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, называется кросс-генерация. Простая кросс-среда - это вторая категория кросс-сред разрабоки.

4.4 Кросс-генерация в целевую среду

Команда:

 ./configure a29k --target=a29k
сконфигурирует утилиты так, что при компилировании в среде разработки, предназначенной для a29k, получаемая среда разработки будет создавать программы, предназначенные для a29k. Это не значит, что новая среда будет работать на 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.

4.5 Канадская кросс-генерация

Итак, мы видим, что наш исходный текст среды разработки необходимо сконфигурировать для определенной основной среды и определенной целевой среды. Также мы видим, что получаемая среда разработки зависит от среды разработки, используемой в процессе компиляции.

Получаемая среда разработки будет родной, если идентичны: основная среда в конфигурации, целевая среда в конфигурации, среда, представляемая средой разработки, используемой для компиляции и машина, на которой наша среда разработки будет работать.

Если совпадают все среды кроме основной среды, то мы можем предположить, что среда разработки используемая для компиляции есть некоторая форма библиотеки эмуляции.

Если не совпадает только целевая среда, то полученная среда разработки будет простой кросс-средой разработки.

Если же исключение составляет основная среда с которой работает среда, используемая для компиляции, то мы имеем процесс "кросс-генерации на", и получаемая среда будет родной для какой-то другой машины.

Большинство других вариантов возможно в некоторой форме, но только следующий представляет интерес.

Команда:

 ./configure a29k --target=sun3
сконфигурирует утилиты, которые после компилирования в среде разработки, предназначенной для a29k можно будет использовать для создания программ, предназначенных для sun3. Новая среда не обязательно будет работать на a29k. Это будет зависеть от среды разработки, использованной для компиляции.

Если Вы следуете руководству, то у Вас уже есть две среды разработки, предназначенных для a29k: родная среда разработки, которая работает на a29k и простая кросс-среда разработки, которая работает на Вашем sun4. Если Вы используете родную среду разработки для a29k на a29k, то Вы сделаете то, что мы уже делали ранее, а точнее простой кросс-компилятор из a29k в sun3. Предположим, что вместо этого вы используете gcc-a29k, простую кросс-среду, которая работает на sun4, но создает программы для a29k.

Полученная среда разработки будет работать на a29k, так как gcc-a29k создает программы для a29k. Это новая среда будет создавать программы предназначенные для sun3, согласно конфигурации. Т.е. полученная среда разработки - это простой кросс-компилятор.

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


Вперед Назад Содержание