[devel] OCaml packaging

Michael Shigorin =?iso-8859-1?q?mike_=CE=C1_osdn=2Eorg=2Eua?=
Сб Дек 23 13:13:08 MSK 2006


On Sat, Dec 23, 2006 at 12:11:04PM +0300, Grigory Batalov wrote:
> Остаётся вопрос из "Проблемы 1": как паковать и паковать ли
> исполняемый байт-код? Ну и вообще, что думает сообщество о
> предложенном материале?

Всё-таки ещё раз порекомендую участникам команды, которым
доводится сталкиваться с принятием неоднозначных решений,
почитать про SWOT-анализ[1], простая же штука.  Разве что
для себя порой воспринимаю "SWOT" как "плюс-минус на
сейчас-завтра" вместо рыночных факторов.

В данном разе я бы нарисовал по минимуму так
(не пытаюсь отабличить, бо ещё разъедется):


1. собирать байткод

Strengths
* переносимость между архитектурами

Weaknesses
* меньшая производительность
* необходимость интерпретатора

Opportunities
-

Threats
* возможность съезда бинарной совместимости,
  которой апстрим не озадачивается, и неочевидных
  грабель


2. собирать натив

Strengths
* большая производительность
* большая компактность (?)

Weaknesses
* непереносимость между архитектурами as-is

Opportunities
-

Threats
-


3. собирать байткод с подвесным интерпретатором

Strengths
* отсутствие зависимости от внешнего интерпретатора

Weaknesses
* меньшая производительность байткода плюс добавленный
  объём VM

Opportunities
* возможность запуска при наличии нативного внешнего 
  интерпретатора на ненативной платформе

Threats
* при сборке пакета "мусор" в виде байткода может быть
  стрипнут при зачистке buildroot => неработоспособность


Из всего этого лично мне как дистрибутивное решение однозначно
видится сборка нативного кода, поскольку все возникающие
(описанные) проблемы закрываются rpm и средой сборки.


[1] http://www.iteam.ru/publications/strategy/section_16/article_1185/print/

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/



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