Слакварное ./configure
Сколько же это сможет продолжатся? Столько сколько это будет возможным.... Матрица часть 3 РЕВОЛЮЦИЯ
Отличительной чертой Slackware подобных дистрибутивов, к которым относится используемый мной MOPS LINUX, является простота, надежность, и как следствие невероятная гибкость и мощь, позволяющая эффективно решать любые задачи. Но владение столь великолепным инструментом почти автоматически заставляет желать большего - большей отзывчивости системы, большего комфорта, наконец.
Итак, задача — взять от железа всё что можно, причем используемая технология должна быть:
- эффективной
- малозатратной
- массовой (легко переносимой на другие компы)
- легкой в управлении и обслуживании
Решение - пересборка приложений под конкретное железо, с обязательной регистрацией в базе установленного софта (пакетного менеджера)
Казалось бы трудностей не возникнет, но — статья, описывающая процесс создания пакетов, не дописана, обрывается на самом интересном месте... На форуме есть много мнений, но нет рецептов. Есть сборка слакбилдами, есть тулза paskadebulder , есть замечательный и функциональный менеджер пакетов, умеющий кроме всего прочего работать с репозиториями — mpkg. Но! Слакбилд надо ещё найти (не всегда удаётся) параметры paskadebulder относительно архитектуры и конфигурации собираемой программы можно задать, но для этого нужно знать, что задать. К тому же оптимизация приложений не так проста, как кажется. Ещё не факт, что программа соберётся с указанными флагами компилятора, и вовсе не факт, что эти флаги будут использованы при сборке. Автоматизировать сей процесс трудно, почти невозможно. Словом опять получается так: скачиваем сырцы
./configure --help
затем курим слакбилд (paskadebulder), выставляя потребные флаги и архитектуру и добиваясь правильной сборки, а не проще ли
./configure && make install ?
В общем, получается как в том анекдоте когда учёные мужи засунули обезьяну внутрь некой конструкции, имеющей только два выхода, и уселись наблюдать какой из двух путей она выберет. Обезьяна нашла третий путь.
Резонный вопрос — а стоит ли этим заниматься? Безусловно! И чем лучше ваш процессор, чем дальше используемая архитектура от стандартной (i486-i686) тем более значительный выигрыш вы получите. Ускоряется всё: файловые операции, работа с сетью, вывод на экран. Массаракш!, такое впечатление,что я не успеваю убрать палец с кнопки, а прога уже запустилась и работает. Глюки и баги оптимизированных прог? А вот не замечал как-то.
Всё нижеизложенное есть по сути компиляция идей с различных форумов и блогов, с поправками на специфику MOPS LINUX и здравого смысла автора. Ну или того, что автор понимает под «здравым смыслом».
Для начала отметим, что пакеты в slackware (да и в Мопсе) это, по сути, архивы tar.gz , а зависимости Мопс держит в файле data.xml, который модно редактировать как угодно. Описывать собственно приемы оптимизации я не стану, инфы в сети достаточно, отмечу лишь, что наиболее эффективные флаги компилятора (далее Фк) под мой 2-х ядерный атлон выглядят так -
CFLAGS="-O3 -march=native -mtune=native -mfpmath=387" CXXFLAGS="-O3 -march=native -mtune=native -mfpmath=387"
Задать их можно либо
Фк ./configure [ параметры проги ] либо
make Фк
Либо непосредственно редактируя Makefile (или *.pro) в случае использования cmake или qmake. В случае qmake искомые параметры нужно можно задавать через скрипт вида
find . -type f -name '*.pro' | while read FILE; do
echo "QMAKE_CXXFLAGS_RELEASE = %Фк" >> "$FILE"
echo "QMAKE_CFLAGS_RELEASE = %Фк" >> "$FILE";
done
Если же используется scons, редактировать нужно файл параметров сборки. Кстати, такой метод — редактирование — есть самый надежный и он же самый затратный, поэтому использую я его только тогда, когда не проходят другие способы (последний довод королей!) :-D Под 2-х ядерный проц лучше задать
make -j4
оно быстрее будет (общая фрмула -j2 * кол-во ядер), но внимательно следите за температурой проца - на таких задачах возможен перегрев, если охлаждение вам делал пьяный китаец Сяо.
За процессом сборки желательно наблюдать лично, часто проги норовят проигноривать заданные опции сборки (используются ли ваши Фк можно узнать из вывода на экран в процессе компиляции). Если же таковые собшения на экан не выводятся (cmake например любит скрывать вывод отладки) - не беда даём команду типа cmake -LAN, и вообще доки рулят.
Теперь, когда сборка и оптимизация закончена:
- Создаём каталог ~/pak (название условное)
- Создаём в нем 2 подкаталога /install и /usr (подразумевается что мы задали--prefix=/usr)
- В подкаталоге install создаём 2 файла: data.xml и slack-desk
data.xml должен иметь следующий вид:
<?xml version="1.0" encoding="utf-8"?>
<package>
<name>
ecikal
</name>
<version>
1.1
</version>
<build>
bdn
</build>
<arch>
4a
</arch>
<short_description>
клиент dс++
</short_description>
<description>
o3 athlon64
</description>
</package>
slack-desk, вообще говоря, обычный тесктовой файл:
psi: psi charts SMP CPU, load, Disk, and all active net interfaces
psi: automatically. An on/off button and online timer for the PPP interface
psi: is provided. Monitors for memory and swap usage, file system, internet
psi: connections, APM laptop battery, mbox style mailboxes, and cpu temps.
psi: Also includes an uptime monitor, hostname label, and clock/calendar.
В МОПС он не используется и я даже не утруждаю себя его заполнением, сохраняю только потому, что туда удобно записывать различные замечания по работе программы, да и менеджер пакетов ругается, если его не находит.
Теперь создаем скрипт сборки:
#!/bin/bash
cd ~/pak/usr
chown -Rc root:root .
find . -perm 777 -exec chmod 755 {} \;
find . -perm 555 -exec chmod 755 {} \;
find . -perm 444 -exec chmod 644 {} \;
find . -perm 666 -exec chmod 644 {} \;
find . -perm 666 -exec chmod 644 {} \;
# Выставляем правильные права и владельца файлов перед инсталляцией
cd ~/pak && tar -czf gk.tgz install/ usr/ &&
# Архивируем
mpkg convert gk* &&
# Конвертируем в формат пакетов мопса
mpkg gendeps2 gk* &&
# Генерируем зависимости
rm gk.tgz &&
rm -rf /home/den/pak/usr &&
mkdir /home/den/pak/usr &&
chown user:users ~/pak/usr
# Чистим за собой
И только теперь выполняем (от пользователя!)
make DESTDIR=~/pak/usr install
В случае сборки cmake это будет
make INSTALLROOT=~/pak/usr install
Возможны и такие конструкции -
make prefix=~/pak install
Ну или:
cmake -DCMAKE_CXX_FLAGS="flags" -DCMAKE_INSTALL_PREFIX="install prefix" - DDATA_INSTALL_DIR="data dir"
Читайте доки для задания правильного префикса! Запускаем paket.sh (**от рута!**) и получаем готовый к инсталляции пакет ecikal-1.1-bdn.tgz (название будет в зависимости от того что написано в data.xml, редактировать его надо каждый раз) в котором прямо указаны зависимости, и который можно сразу же инсталлировать командой
mpkg install ecikal-1.1-bdn.tgz
Отмечу, что по данной методике собрано уже порядка 30-ти программ и они установлены на 50-ти с гаком компах, всё нормально работает. Менджер пакетов МОПСа довольно умен, сам добавляет в пакет не только зависимости но и скрипты очистки от старых библитек, т.е если я ставлю новую версию уже сушествуюшей проги она нормально обновляется и регистрируется в базе.