8.2.2 Поиск и устранение проблем в конфигурационном скрипте

Теперь, когда у нас есть представление о том, что делает конфигурационный скрипт, попробуем посмотреть, что может пойти не так. Есть два сигнала о проблеме. Один из них, когда конфигурационный скрипт корректен, а ваша система действительно не соответствует условию. Чаще всего это будет правильно диагностировано конфигурационным скриптом. Более тревожный случай, когда скрипт конфигурации является некорректным. Это может привести либо к неспособности создавать конфигурацию, или к созданию неправильной конфигурации. В первом случае, когда конфигурационный скрипт обнаруживает, что есть несоответствие условию, обычно большинство конфигурационных скриптов достаточно хороши, чтобы вывести подходящее сообщение об ошибке, описывающее требуемую версию отсутствующего компонента. Всё, что мы должны сделать, это установить этот необходимый отсутствующий компонент и перезапустить скрипт конфигурации. Ниже приведены некоторые советы по устранению проблем, связанных с конфигурационным скриптом.

▪Прочитайте README и посмотрите параметры настройки в ./configure --help: там может быть какие-нибудь специальный параметр для указания пути к какой-то зависимой библиотеке, который если не указан, может по умолчанию содержать неправильную информацию о пути.

▪Изобразите графически дерево зависимостей: будьте внимательны при чтении проектной документации и запишите зависимые библиотеки и требования к номерам версий. Это позволит вам сэкономить много времени. Например, библиотека GTK зависит от библиотеки GLIB, которая зависит от библиотек ATK и PANGO. Библиотека PANGO, в свою очередь, зависит от библиотеки FREETYPE. Лучше иметь удобную диаграмму зависимостей, чтобы собрать и установить независимые узлы (библиотеки) в дерево, а затем скомпилировать родителя (библиотеку).

▪Пробный запуск на ix86: иногда перед кросс-компиляцией для понимания работы скрипта и его зависимостей может быть полезным выполнение скрипта конфигурации на x86.

▪Учитесь читать config.log: когда запускается конфигурационный скрипт, он создаёт файл под названием config.log. Этот файл хранит полный протокол пути выполнения этого скрипта. Каждая строка хранит точную команду оболочки, которая выполняется. Тщательное чтение файла журнала покажет, какой тест выполняется, и поможет вам понять причину неудачи.

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