[devel] Q: site-lisp files

Dmitry V. Levin =?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Пн Окт 28 02:10:46 MSK 2002


On Sun, Oct 27, 2002 at 07:57:54PM +0300, Ivan Zakharyaschev wrote:
> > Выводы:
> > - Пакеты, содержащие файлы только одного из двух видов, очевидно,
> >   делают это ошибочно.
> 
> Может быть, это не совсем чисто с точки зрения упаковки, но на
> возможность использования это почти никак не влияет:
> 
> - и .elc, и .el могут быть загружены для использования во время работы
> (.el чуть медленнее, есть бОльшая вероятность возникновения ошибки при
> этом);
> 
> - .el как правило не нужны: с ними удобнее заниматься debugging, изучать
> исходники и т.п. Когда их мало, самое удобное решение -- положить в
> пакет вместе с .elc; когда много -- в отдельный пакет.
> 
> - И те и другие можно сжимать (gzip или bzip2). .elc я предпочитаю не
> сжимать (мне кажется, это может замедлить загрузку), разве что большие и
> редко используемые, а .el неплохо бы и сжать (в TODO к emacs-el).

Значит, .elc мы рекомендуем включать (по аналогии с .pyc/.pyo)?

> > - Есть смысл все .el?-файлы вынести из основных пакетов.
> 
> Не знаю, есть ли смысл. По-моему, это создаст неудобства и для
> пользователя и для packager-а: пользователь ожидает, что если у него
> установлены Emacs и, скажем, gpm, то они смогут взаимодействовать друг с
> другом. Если же gpm не установлен, то поддержка gpm в Emacs не нужна:
> только место и время загрузки отнимает. (gpm, может, не самый удачный
> пример, т.к. gpm -- не что-то редкое.)
> 
> Сейчас, по-моему, довольно естественная ситуация с тем, где лежат
> el?-файлы, и их перемещение -- лишняя работа packager-ов (причём не
> разовая, а постоянная), да ещё, на мой взгляд, не приносящая улучшений.
> 
> Какие есть варианты, куда класть el-бтблиотеку для взаимодействия:
> 
> 1) в пакет с той программой, с которой она взаимодействует и вместе с
> которой рапространяется el-исходник. Это примерно то, что сейчас есть, и
> мне этот вариант больше всего и нравится. Лишних зависимостей от Emacs
> это не создаёт (кроме тех, что при сборке), но даёт удобства
> пользователю и packager-у: пользователь поставил emacs и эту программу и
> работает;  вышла новая версия программы, packager пересобрал пакет, и ни
> о чём больше думать не надо: el-библиотека, входящая в него, нормально
> работает с новой версией, никакие другие пакеты в связи с этим изменять
> не надо.

Если бы еще и .elc-файлы создавались автоматически (как .pyc/.pyo), и не
вытягивали вместе с emacs'ом жуткие сборочные зависимости...
С ними, кстати, можно что-нибудь сделать?


--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20021028/446bc332/attachment-0001.bin>


Подробная информация о списке рассылки Devel