Администрирование локальных сетей

Для создания fonts.dir файла достаточно запустить mkfontdir указав ей в качестве аргумента директорию со шрифтами.

Компилирование .BDF шрифтов в .PCF шрифты.

Растровые шрифты в системе Х11 могут быть представлены в нескольких формах:

• .pcf Переносимый бинарный формат описания шрифта

• .pcf.Z компрессированный .pcf

• .bdf текстовый формат

• .bdf.Z компрессированный .bdf

• .bcf компрессированный .bdf

• .snf не переносимый бинарный формат шрифта (использовался до X11R5)

• .snf.Z компрессированный .snf (использовался до X11R5)

• .scf компрессированный .snf (использовался до X11R5)

• 
  

Предпочтительным форматом для Х сервера является компрессированый .pcf.

Для конвертации .bdf в .pcf с одновременной компрессией можно воспользоваться командой:

bdftopcf font_file.bdf | compress > font_file.pcf.Z

4. Программирование на HP-UX

Для создания выполняемых програм, нужно скомпилировать исходный код где содержиться главная програма.

Расмотрим пример компиляции.

$ cc –Aa myprog.c

Процес компиляции покадет все сообщения (статус,предупреждения, ошибки) на стандартный поток вывода ошибок (stderr). После этого компилятор создаст файл a.out который уже можно запускать. Аналогично можно скомпиларовать Фортрановскую прогамму командой f77. Если програма состоит из несколько файлов, то омпиляция будет выглядет следующем образом:

$ cc –Aa main.c myfunc.c

main.c:

myfunc.c:

после этого можно будет запускать a.out.

Можно сказать что процес компиляции похожий как на рисунке:

На самом деле процесс компиляции намноого сложнее. Этот процес компиляции занимает несколько этапов.

1. Для каждого исходного файла запускаеться компилятор который создает обьектный файл (если исходные коды написаны на разных языках програмирования, то для каждого запускаеться тот соотвествующий компилятор)

2. После компиляция (этап создания) обьектных файлов запускаеться линковщик (HP-UX linker (ld))

На картинке можете увидеть более детальный процес компиляции:

Для более детального просмтотра этапов прохождения компиляции, можно посмотреть задав опцию –v (verbose)

$ cc -Aa -v main.c myfunc.c

cc: CCOPTS is not set.

main.c:

/opt/langtools/lbin/cpp.ansi main.c /var/tmp/ctmAAAa16327 -D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -D_PA_RISC1_1

cc: Entering Preprocessor.

/opt/ansic/lbin/ccom /var/tmp/ctmAAAa16327 main.o -Oq00,al,ag,cn,Lm,sz,Ic,vo,lc,mf,Po,es,rs,sp,in,vc,pi,fa,pe,Rr,Fl,pv,pa,nf,cp,lx,st,ap,Pg,ug,lu,dp,fs,bp,wp! -Aa

myfunc.c:

/opt/langtools/lbin/cpp.ansi myfunc.c /var/tmp/ctmAAAa16327 -D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -D_PA_RISC1_1

cc: Entering Preprocessor.

/opt/ansic/lbin/ccom /var/tmp/ctmAAAa16327 myfunc.o -Oq00,al,ag,cn,Lm,sz,Ic,vo,lc,mf,Po,es,rs,sp,in,vc,pi,fa,pe,Rr,Fl,pv,pa,nf,cp,lx,st,ap,Pg,ug,lu,dp,fs,bp,wp! -Aa

cc: LPATH is /usr/lib/pa1.1:/usr/lib:/opt/langtools/lib:

/usr/ccs/bin/ld /opt/langtools/lib/crt0.o -u main main.o myfunc.o -lc

cc: Entering Link editor.

Из этого примера можно посмотреть такие этапы

cpp.ansi это С препроцесор после этого запускаеться /lib/ccom – эта програма(компилятор) уже создает .о файлы. Последний этап это этап создания исполняемого кода, это Линкер, которые связывает все обьекты .

Что такое Обьектный файл ?

Обьектный файл содержет машиные инструкции а данные с которых линкеровщик создает исполняемую програму. Каждий обьектный файл содержит НАЗВАНИЕ (symbol name) и ссылку на это название.

Названия делятся на 3 категории:

1. Локальные обьявления (local definition) – это коды или данные которые могут использоваться только в том обьектном файле где они обьявленые.

2. Глобальные обьявления (global definition) – это обьявления прорцедур,функций,данных котоые могут быть доступны из других обьектных файлов

3. Внешние ссылки (extern references) – это обьявления которые глобальный инаходяться в других обьектных файлах.

Для просмотра обявлений успользуеться програма nm.

Этап линкирования.

Линкирование это последний этап создания запускания файлов, он в включает в a.out файл все ссылки обьявлений и их реализации , которые встречаються в програме. Если например есть сылка а нет реализаци то линкировщик скажет что не находит внешнего обявления и выдаст следюющее:

$ cc main.c

/bin/ld: Unsatisfied symbol:

my_func (code)

Работа с библиотеками

Очень полезным средсвом для хранения сылски реализаций внешних обьявлений есть библиотеки. Стандартная библиотека libc которая содержит «основные» функции для C,Fortran

Библиотеки называються libname.sfx

Name – название библиотеки, которая идентефецирует библиотеку

Sfx - если .а – архив, .sl – общедоступная библиотека.

Для того что б указать компилятору библиотеку то указываеться через опцию –l. Например

--lm (подключает стандартну математическую библиотеку libm.a).

По умолчанию подключаються библиотеки libcl,libisamstub,libc.

По умолчанию библиотеки ищатся по путям /lib,/usr/lib,lib/libp. Можно задать пути где искать:

1. Переменой коружения LPATH

2. Опция линкера -L

Также для каждой програмы входит обьектный файл /lib/crt0.o В этом файле содержаться таочки входа в програму,простомтр аргументов и прочее.

Можна прочитать о фунциях которые есть в стандартных библиотеках исполюзую man-page

Вызовы (функции) описываються следующим образом

Name(nL)

Name – название

N – 2-системные вызовы, 3-другие библиотеки

L – буква которая означает к которой библиотеке вызов относиться

Вот примеры:

Опции компилятора cc

cс [option] files

• -Amode

• mode=c По умолчанию, стандартный компилятор С (по Керниган, Риттчи)

• mode=a ANSI C (ISO 9899:1990)

• mode=e Расшириное ANSI C

• -c Отменить фазу редактирования связей и создавать об'ектный файл даже в случае программы, состоящей только из одного модуля.

• -p Сгенерировать дополнительные команды для подсчета числа обращений к каждой функции. Кроме того, если имеет место фаза редактирования связей, стандартная подпрограмма инициализации заменяется на такую, которая автоматически вызывает функцию monitor(3C) и обеспечивает запись файла mount.out при нормальном завершении об'ектной программы. Профиль выполнения программы может быть затем получен при помощи команды prof(1).

• -Dname=def определяет макрос для препроцесорра (эквивалентно #define )

• -E посылает на стандартный поток вывода (по умолчанию на stderr)

• -g содержит дополнительную информацию для отладки

• -Idir Изменить алгоритм поиска включаемых (посредством директивы #include) файлов, имена которых не начинаются с символа /, а именно: сначала искать в указанном каталоге, а затем уже в каталогах стандартного списка. Так, включаемые файлы, чьи имена заданы в двойных кавычках, сначала ищутся в каталоге, содержащем файл, затем в каталогах, указанных с помощью опции -I, а затем уже в каталогах стандартного списка. Включаемые файлы, чьи имена заданы в угловых скобках, не ищутся в каталоге, содержащем файл.

• -lname включает библиотеку

• -L dir dir= Дополнить каталогом список каталогов, которые содержат об ектные библиотечные модули [для редактирования связей посредством ld

• -v расширынай информация о процессе компиляции

• -w не показывает предупреждений

• -Wx,arglist передает аргументы (опции) arglist для процеса. x

может принимать значения:

• d Driver

• p Preprocessor

• c Compiler

• a Assembler

• l Linker

• +z,+Z Опция создает PIC код

• -O Включить оптимизацию обьектного кода

Создание архивной библиотеки.

1. Для открытия библиотеки необходимо создать оььектные файлы. (в основном каждая функция представляет свой обьектный файл)

2. Соеденить все обьекты в один архив командой ar с ключем r

Описание команды ar

ar [-][d][r][q][t][p][m][x][v][c][l][s] [позиционирующее_имя]

а_файл [имя ...]

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

При создании архива командой ar заголовки файлов строятся в формате, не зависящем от конкретной машины. Формат и структура мобильного архива подробно описаны в ar(4). Таблица имен архива (описанная там же) используется редактором связей [ld(1)] для сокращения числа проходов по библиотекам об ектных файлов. Команда ar создает и поддерживает таблицу имен только при наличии в архиве хотя бы одного об ектного файла. Таблица имен в случае ее создания помещается в начале архива в качестве файла с особым именем. Ни ссылка на этот файл, ни доступ к нему для пользователя невозможны. При создании или изменении архива командой ar(1) таблица имен всякий раз перестраивается. Таблицу имен можно перестроить принудительно, воспользовавшись описанной ниже опцией s.

В отличие от командных опций командный ключ составляет обязательную часть командной строки ar. Ключ (которому может предшествовать символ -) представляет собой один из символов набора drqtpmx. Аргументами же ключа могут служить один или несколько символов из набора vuaibcls. Позиционирующее_имя - это имя элемента архива, которое используется в качестве указателя конкретного места архива, куда должны помещаться другие файлы. А_файл - это имя архивного файла. Под именами подразумеваются имена файлов, входящих в архив. Символам, образующим ключ, приписан следующий смысл:

Аргументам ключа приписан следующий смысл:

Открытие Библиотек Распределеного доступа

Первый шаг в создание общедоступной библиотеки должен создать объектные файлы,

cодержащий переместимый код (PIC). Имеются два способа создать

PIC объектные файлы:

• Компилировать исходные файлы с + z или + Z опция компилятора, описанная ниже.

• Записать программы на языке ассемблера, которые используют соответствующее адресование режимы

• 
  

+ z и + Z параметры вынуждают компилятор генерировать PIC объектные файлы.

Пример

Предположите, что Вы имеете некоторые функции C, сохраненные в length.c, которые конвертируют(преобразовывают) между Английскими и Метрическими модулями длины. Для компилиции эти подпрограммы и создайние PIC объектных файлов с компилятором C, Вы можете бы использовать эту команду:

$ cc -Aa -c +z length.c

+z опция создает PIC.

Создание Общедоступной Библиотеки с ld

Чтобы создавать общедоступную библиотеку от одного или большее количество PIC объектные файлы, используйте линкер ld, с -b опцией. По умолчанию, ld назовет библиотеку а.out. Вы можете изменять название с -o опцией.

Например, предположите, что Вы имеете три исходных файла C, содержащие подпрограммы, чтобы делать длину, объем, и массовые преобразования модуля. Они названы length.c, volume.c, и mass.c, соответственно. Делать общедоступную библиотеку от этих исходных файлов, сначала компилируют все три файла, использующие +z опцию, затем комбинируют заканчивающиеся .o файлы с ld. Показаны ниже команды, которые Вы использовали бы, чтобы создать общедоступную библиотеку, названную libunits.sl:

$ cc -Aa -c + z length.c volume.c mass.c

length.c:

volume.c:

mass.c:c:

$ ld -b -o libunits.sl length.o volume.o mass.o

Как только библиотека создана, убедитесь наличия прав читения и выполнения.Но можна выставить права такой командой

$ chmod +r+x libunits.sl

Например, если Вы имеете программу c названным convert.c, который вызываетподпрограммы с libunits.sl, Вы могли бы компилироватьИ связь это с командой cc:

$ cc -Aa convert.c libunits.sl

Как только выполнимая программа создана, библиотека не должна быть перемещена потому что

абсолютное имя пути библиотеки сохранено в выполнимой программе

Модифицирование Общедоступной Библиотеки

Команда ld не может заменять или удалять объектные модули в общедоступной библиотеке. Поэтому, чтобы модифицировать общедоступную библиотеку, Вы должны повторно связать библиотеку со всеми объектными файлами, которые Вы хотите, чтобы библиотека включила. Например, предположите, что Вы устанавливаете некоторые подпрограммы в length.c (от предыдущего раздела) которые давали неправильные результаты. Чтобы модифицировать libunits.sl библиотеку, чтобы включить эти изменения(замены), Вы использовали бы этот ряд команд:д:

$ cc -Aa -c + z length.c

$ ld -b -o libunits.sl length.o volume.o mass.o

Любые программы, которые используют эту библиотеку, будут теперь использовать новые версии подпрограмм. То есть Вы не должны повторно связать никакие программы, которые используют эту общедоступную библиотеку. Это - то, потому что подпрограммы в библиотеке приложены к программе во время выполнения.я.

Это - одно из преимуществ общедоступных библиотек по библиотекам архива: если Вы изменяете(заменяете) библиотеку архивов, Вы должны повторно связать любые программы, которые используют библиотеку архивов. С общедоступными библиотеками, Вы должны только освежить библиотеку.

Применение make

Создание программы частенько начинается с маленького однофайлового проекта. Проходит некоторое время и проект, как снежный ком, начинает обрастать файлами, заголовками, подключаемыми библиотеками, требуемыми опциями компиляции... и для его сборки становится уже недостаточным сказать "cc -o file file.c". Когда же, через пару дней, однажды набранная магическая строчка, содержащая все необходимые для сборки проекта параметры компилятора, таинственно исчезает в недрах истории вашего командного интерпретатора, рождается естественное желание увековечить свои знания в виде, к примеру, шелл скрипта. Затем, возможно, захочется сделать этот скрипт управляемым параметрами, чтобы его можно было использовать для разных целей... Однако, чудо юникса состоит в том, что если вам что-то понадобилось, значит кто-нибудь это уже сделал, и пришло время вспомнить о существовании команды make.

Рассмотрим несложную программу на C. Пусть программа prog состоит из пары файлов кода main.c и supp.c и используемого в каждом из них файла заголовков defs.h. Соответственно, для создания prog необходимо из пар (main.c defs.h) и (supp.c defs.h) создать объектные файлы main.o и supp.o, а затем слинковать их в prog. При сборке вручную, выйдет что-то вроде:

cc -c main.c defs.h

cc -c supp.c defs.h

cc -o prog main.o supp.o

Если мы в последствии изменим defs.h, нам понадобится полная перекомпиляция, а если изменим supp.c, то повторную компиляцию main.о можно и не выполнять. Казалось бы, если для каждого файла, который мы должны получить в процессе компиляции указать, на основе каких файлов и с помощью какой команды он создается, то пригодилась бы программа, которая во-первых, собирает из этой информации правильную последовательность команд для получения требуемых результирующих файлов и, во-вторых, инициирует создание требуемого файла только в случае, если такого файла не существует, или он старше, чем файлы от которых он зависит. Это именно то, что делает команда make! Всю информацию о проекте make черпает из файла Makefile, который обычно находится в том же каталоге, что и исходные файлы проекта.

Простейший Makefile состоит из синтаксических конструкций всего двух типов: целей и макроопределений.

Цель в Makefile - это файл(ы), построение которого предполагается в процессе компиляции проекта. Описание цели состоит из трех частей: имени цели, списка зависимостей и списка команд интерпретатора sh, требуемых для построения цели. Имя цели - непустой список файлов, которые предполагается создать. Список зависимостей - список файлов, из которых строится цель. Имя цели и список зависимостей составляют заголовок цели, записываются в одну строку и разделяются двоеточием. Список команд записывается со следующей строки, причем все команды начинаются с обязательного символа табуляции. Возможна многострочная запись заголовка или команд через применение символа "" для экранирования конца строки. При вызове команды make, если ее аргументом явно не указана цель, будет обрабатываться первая найденная в Makefile цель, имя которой не начинается с символа ".". Примером для простого Makefile может послужить уже упоминавшаяся программа prog:

prog: main.o supp.o

cc -o prog main.o supp.o

main.o supp.o: defs.h

В прведенном примере можно заметить ряд особенностей: в имени второй цели указаны два файла и для этой же цели не указана команда компиляции, кроме того, нигде явно не указана зависимость объектных файлов от "*.c"-файлов. Дело в том, что команда make имеет предопределенные правила для получения файлов с определенными суффиксами. Так, для цели - объектного файла (суффикс ".o") при обнаружении соответствующего файла с суффиксом ".c", будет вызван компилятор "сс -с" с указанием в параметрах этого ".c"-файла и всех файлов - зависимостей. Более того, в этом случае явно не указанные ".c"-файлы make самостоятельно внесет в список зависимостей и будет реагировать их изменение так же, как и для явно указанных зависимостей. Впрочем, ничто не мешает указать для данной цели альтернативную команду компиляции.

Вы вероятно заметили, что в приведенном Makefile одни и те же объектные файлы перечисляются несколько раз. А что, если к ним добавится еще один? Для упрощения таких ситуаций make поддерживает макроопределения.

Макроопределение имеет вид "ПЕРЕМЕННАЯ = ЗНАЧЕНИЕ". ЗНАЧЕНИЕ может являться произвольной последовательностью символов, включая пробелы и обращения к значениям уже определенных переменных. В дальнейшем, в любом месте Makefile, где встретится обращение к переменной-макроопределению, вместо нее будет подставлено ее текущее значение. Обращение к значению переменной в любом месте Makefile выглядит как $(ПЕРЕМЕННАЯ) (скобки обязательны, если имя переменной длиннее одного символа). Значение еще не определенных переменных - пустая строка. С учетом сказанного, можно преобразовать наш Makefile:

OBJS = main.o supp.o

prog: $(OBJS)

cc -o prog $(OBJS)

$(OBJS): defs.h

Теперь предположим, что к проекту добавился второй заголовочный файл supp.h, который включается только в supp.c. Тогда Makefile увеличится еще на одну строчку:

supp.o: supp.h

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

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

OBJS = main.o supp.o

prog: $(OBJS)

cc -o prog $(OBJS)

main.o: defs.h

supp.o: defs.h supp.h

Обычно Makefile пишется так, чтобы простой запуск make приводил к компиляции проекта, однако, помимо компиляции, Makefile может использоваться и для выполнения других вспомогательных действий, напрямую не связанных с созданием каких-либо файлов. К таким действиям относится очистка проекта от всех результатов компиляции, или вызов процедуры инсталляции проекта в системе. Для выполнения подобных действий в Makefile могут быть указаны дополнительные цели, обращение к которым будет осуществляться указанием их имени аргументом вызова make (например, "make install"). Подобные вспомогательные цели носят название фальшивых, что связанно с отсутствием в проекте файлов, соответствующих их именам. Фальшивая цель может содержать список зависимостей и должна содержать список команд для исполнения. Поскольку фальшивая цель не имеет соответствующего файла в проекте, при каждом обращении к ней make будет пытаться ее построить. Однако, возможно возникновение конфликтной ситуации, когда в каталоге проекта окажется файл с именем, соответствующим имени фальшивой цели. Если для данного имени не определены файловые зависимости, он будет всегда считаться актуальным (up to date) и цель выполняться не будет. Для предотвращения таких ситуаций make поддерживает "встроенную" переменную ".PHONY", которой можно присвоить список имен целей, которые всегда должны считаться фальшивыми.

Теперь можно привести пример полного Makefile, пригодного для работы с проектом prog и принять во внимание некоторые часто применяемые приемы:

OBJS = main.o supp.o

BINS = prog

PREFIX = /usr/local

INSTALL = install

INSOPTS = -s -m 755 -o 0 -g 0

CC = gcc

.PHONY = all clean install

all: $(BINS)

prog: $(OBJS)

$(CC) -o prog $(OBJS)

main.o: defs.h

supp.o: defs.h supp.h

clean:

rm -f $(BINS)

rm -f $(OBJS)

rm -f *~

install: all

for $i in $(BINS) ; do

$(INSTALL) $(INSOPTS) $$i $(PREFIX)/bin ;

done

Итак, у нас появились три фальшивых цели: all, clean и install. Цель all обычно используется как псевдоним для сборки сложного проекта, содержащего несколько результирующих файлов (исполняемых, разделяемых библиотек, страниц документации и т.п.). Цель clean используется для полной очистки каталога проекта от результатов компиляции и "мусора" - резервных файлов, создаваемых текстовыми редакторами (они обычно заканчиваются символом "~"). Цель install используется для инсталляции проекта в операционной системе (приведенный пример расчитан на установку только исполняемых файлов). Следует отметить повсеместное использование макроопределений - помимо всего, этот прием повышает читабельность. Обратите также внимание на определение переменной $(CC) - это встроенная переменная make и она неявно "сработает" и при компиляции объектных файлов.

Внутренние макросы
Мake поддерживает пять внутренних макросов, полезных при написании правил построения целевых файлов:

$*

Этот макрос является именем файла без расширения из текущей зависимости; вычисляется только для подразумеваемых правил (см. Суффиксы).

$@

Этот макрос заменяется на полное имя целевого файла; вычисляется только для явно заданных зависимостей.

$<

Вычисляется только для подразумеваемых правил или для правила .DEFAULT. Этот макрос заменяется на имя файла, от которого по умолчанию зависит целевой файл. Так, в правиле .c.o макрос $< будет заменен на имя файла с расширением .c. Например, правило для изготовления оптимизированного об ектного файла из файла с расширением .c может быть таким:

.c.o:

cc -c -O $*.c

или

.c.o:

cc -c -O $<

$?

Макрос $? можно использовать в явных правилах make-файла. Этот макрос заменяется на список файлов-источников, которые изменялись позднее целевого файла.

$%

Этот макрос применяется только тогда, когда целевой файл указан в виде библ(файл.o), что означает, что он находится в библиотеке библ. В этом случае $@ заменяется на библ (имя архива), а $% заменяется на настоящее имя файла, файл.o.

Четыре из этих макросов имеют альтернативную форму. Если к любому из этих макросов добавлено F, то он заменяется на соответствующее макросу имя файла без имени каталога; если же добавлено D, то макрос заменяется на остальную часть значения первоначального макроса без последнего символа /, то есть на имя каталога. Так, $(@D) соответствует каталогу из $@. Если каталог не указан, то генерируется текущий каталог (.). Только макрос $? не имеет альтернативной формы.

Библиотеки

Если целевой файл или имя из списка зависимостей содержит скобки, то оно рассматривается как имя архивной библиотеки, а цепочка символов в скобках - как имя элемента библиотеки. Так, и библ(файл.o), и $(БИБЛ)(файл.o) обозначают библиотеку, содержащую файл.o (предполагается, что макрос БИБЛ был предварительно определен). Выражение $(БИБЛ)(файл1.o файл2.o) недопустимо. Правила обработки библиотечных файлов имеют вид .XX.a, где XX - суффикс, по которому будет получен элемент библиотеки. К сожалению, в текущей реализации требуется, чтобы XX отличался от суффикса элемента библиотеки. Например, нельзя, чтобы библ(файл.o) зависел от файл.o явно. Наиболее общее использование интерфейса работы с библиотеками следующее (предполагается, что исходными являются файлы на языке C):

lib: lib(file1.o) lib(file2.o) lib(file3.o)

@echo lib is now up-to-date

.c.a:

$(CC) -c $(CFLAGS) $<

$(AR) $(ARFLAGS) $@ $*.o

rm -f $*.o

Фактически, правило .c.a, приведенное выше, встроено в make. Более интересный, но более ограниченный пример конструкции, поддерживающей работу с библиотеками:

lib: lib(file1.o) lib(file2.o) lib(file3.o)

$(CC) -c $(CFLAGS) $(?:.o=.c)

$(AR) $(ARFLAGS) lib $?

rm $? @echo lib is now up-to-date

.c.a:;

Здесь используется режим подстановки расширений макросов. Список $? определен как множество имен об ектных файлов (в библиотеке lib), чьи исходные C-файлы были изменены. Подстановка заменяет .o на .c. (К сожалению, нельзя еще трансформировать в .c~; однако, это может стать возможно в будущем). Заметим также, что запрещается правило .c.a:, создающее каждый об ектный файл один за другим. Эта конструкция значительно ускоряет обновление библиотек, но становится весьма