From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 23 Dec 2006 12:13:08 +0200 From: Michael Shigorin To: devel@lists.altlinux.org Message-ID: <20061223101308.GU12587@osdn.org.ua> Mail-Followup-To: devel@lists.altlinux.org References: <20061223121104.5aa2fa0f.bga@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20061223121104.5aa2fa0f.bga@altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: Re: [devel] OCaml packaging X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2006 10:13:13 -0000 Archived-At: List-Archive: List-Post: 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 ------ Linux.Kiev http://www.linux.kiev.ua/