Как организовать сборку проекта на Java но с кусками нативного кода?
Добрый день!
Занимаюсь сейчас своим опен-сорс проектом Octclipse (плагин к Eclipse IDE для Octave), но сообщества пока нет, так что задам вопрос здесь.
Суть проблемы:
Есть проект, в основном написанный на Java, но для некоторых важных фич (консоль, дебаг, графики) требующий С++-кода. Проект я хочу поддерживать на разных платформах(Linux, Window, Mac) и архитектурах(32,64). Также хочется иметь поддержку разных версий Octave(на данный момент — 3.2.4, 3.4.3, 3.6.0). Итого для каждой комбинации получается туча библиотек, собирать которые очень неудобно.
Вопрос:
Есть ли у вас какие-нибудь идеи, как это организовать без излишних сложностей? Ниже я приведу варианты, о которых я думал — хотелось бы услышать и их оценку. Мне важен не столько технический аспект, сколько архитектурный.
Доп. информация:
0. Нативный код не простой, а оформляется в виде плагинов к октейву(по-моему, необходимо это только в случае с графиками). Значит, собирается он не GCC, а октейвовской командой mkoctfile.
1. Сейчас нативный код собирается с помощью AutoTools и только в Linux.
2. Java-код собирается с помощью Maven 3 и Tycho (это всё же плагин к эклипсу)
Варианты (и моё к ним отношение):
— даём пользователям код, просим собрать перед использованием (отпугнет половину пользователей)
— немного извращаемся, таскаем код вместе с плагином, при первом запуске плагина пытаемся вызвать mkoctfile и собрать нужные подпроекты (тяжело, но, вроде, реализуемо)
— отдельно собирать и предлагать доп. пакеты для каждой платформы, версии и дистрибутива(очень трудоёмко в поддержке и некрасиво)
— собирать нативные подпроекты и складывать их в эклипсовские фрагменты (соответственно, пользователи сразу будут получать готовую к употреблению среду, но придется сохранять скомпилированные пакеты в репозитории)
Был ли у кого-нибудь опыт по поддержке чего-то подобного? Посоветуйте, пожалуйста, как быть?
Для разных версий ОС и разной архитектуры машины все равно придется распространять разные дистрибутивы.
Так что остаются только разные версии eclipse и octave. Тут можно просто собрать все варианты и запихнуть в инсталлятор, а при установке детектировать (или спрашивать) необходимые версии ПО и соответственно устанавливать ту, которая подойдет.
Ага, ну это, собственно и есть вариант 4 (с фрагментами). Типа, update site содержит всё, а скачивается только то, что нужно. Именно так я сейчас и сделал, но смущает раздувшийся до невероятных размеров репозиторий (а он hg, потому это критично) из-за хранения в нем скомпилированных библиотек.
Может, убрать их из репозитория и подтягивать откуда-то из другого места?..
Ну мне сдается, это еще сложнее будет.
Я бы, перфекционизма ради, инкапсулировал платформо- и версио-зависимые штуки в отдельные легковесные бинарники. Но это, конечно, сработает, только если они будут действительно легковесные.
Да они и так уже разбиты :) Но, блин, по 2 мегабайта на каждую из 4х библиотек под-проектов, под каждую из комбинаций платформа-версия (~ 15) это уже очень много. Так ведь и любое изменение в С-коде(после коммита) добавляет еще столько же.
Оуу, многовато :)
Ну пока можно оставьте как есть, как будет нехватать места, можно будет думать, чтобы откуда-то еще подгружать бинарники.
А вообще, почему, собственно, по 2 мегабайта? Неужели не получается тонкую прослойку организовать просто?
Не знаю, я не очень силен в оптимизациях кода на С, но так получается, что даже простенький .oct файл весит достаточно много (helloworld.oct = 700Кб). Ну а при добавлении нужных мне удобных библиотек (например, POCO), завязки на liboctinterp, выросло до 2Мб.
Хе, я, кажется, нашел способ, который мне нравится больше всего. duns.github.com/maven-nar-plugin — способ собирать С++-подпроекты с помощью Maven(как и остальной проект). Этот подход оставит фрагменты как способ доставки сборок пользователям, но зато избавит от необходимости хранить сборки в hg. В теории хорошо, попробую так. Если получится — напишу как отдельный ответ к этому вопросу. А то и статью оформлю.
Приемлемое решение найдено. Как писал в комментарии выше, решил использовать плагин duns.github.com/maven-nar-plugin. Стоит отметить, что он сыроват, и по-моему, уже ко всему прочему мертв(последний коммит в 2010 году). Но в какой-то мере своё предназначение выполняет. Мне только пришлось перековырять его код и добавить возможность различать пакеты не только по связке AOL(Architecture,OS,Linker), а еще и по дополнительным классификаторам, в которые я теперь пишу версию Octave.
Думаю, когда всё это реализую, можно будет и статейку написать. Хотя, конечно, спектр применимости у NAR-плагина весьма узкий.
Спасибо за совет, я уже давно на него посматриваю, но в данной ситуации мне очень не будет хватать Tycho(Maven-плагин для сборки плагинов к Eclipse). А вообще тут больше стоял вопрос правильности подхода. И пока я склонился к идее, что надо компилировать под все варианты клиентского окружения самому, но сборки класть не в репозиторий к исходникам, а в Maven-репозиторий.
А так да — не сомневаюсь, что можно то же самое реализовать с помощью Gradle. Может даже попробую чуть позже.
Средний
