Компиляция модульных приложений

EvilBeaver commented 8 years ago

Originally reported by: EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver)

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

Вопрос - что делать с зависимостями по библиотекам.

собирать и включать в exe (embeding)
оставлять зависимостями (linking)

Второй вопрос - надо ли это в 1.0

Bitbucket: https://bitbucket.org/EvilBeaver/1script/issue/199

EvilBeaver commented 8 years ago

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

Цель реализации задачи - более простой деплой приложения с учетом всех библиотек. Я, как и @allustin против распространения приложения в виде EXE. А вот когда надо зафиксировать все зависимости и запулить приложение куда-то на сервер (или в контейнер), где оно будет жить - вот для этого пригодится.

EvilBeaver commented 8 years ago

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

"allustin" - вот такой никнейм тут

@vsuh - то что вы хотите методологически ;-) плохо. Положить 2 файла exe и cfg и добавить задачу в cron - также должны скриптоваться. Такое вот евангелистическое скотство - я обязан это сказать. Тогда в мануал добавляется 3 команды:

msi install oscript
opm install super-scripts --local \\share\oscripts-our-libs\super-script
super-script --init

а в super-script добавляется модули типа

Процедура СпроситьНастройкиКонфигурации()
Процедура СпроситьАдресКаталогаDir()
Процедура СпроситьПараметрыCronOrTaskSheduler()

И тогда не нужны exe файлы.

Но это евангелистически . Практически еаверное стоит добавлять простое компилирование в макроядро типа embedding и на этом остановится. Рисков вроде как меньше.

EvilBeaver commented 8 years ago

Original comment by Valery Sukhikh (Bitbucket: vsuh, GitHub: vsuh):

Незнай, как к вам через @ обратиться я хочу, иметь возможность написать в мануале: Положьте 2 файла exe и cfg в каталог dir, поправьте конфиг и заведите задачу в task manager или cron.

EvilBeaver commented 8 years ago

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

@EvilBeaver кстати в целях переносимости мы в свое время же придумали подход.

В стандартный образ "любого" Windows включается 2 пакета:

oscript интерпретатор
msgit

Делалось это в целях развития 1С разработчиков и в целях наращивания библиотек oscript-library

Если развивать компилятор - то получается есть еще 2 проблемы. По какому пути пойдем:

есть linux way - когда каждая утилита атомарна и коммуницирует с другими через pip'ы (или как они там называются точно)
есть не linux way - когда все импортируемые пакеты включаются в итоговый exe/bin
есть еще lib way - когда мы указываем линковку библиотек

Во всех трех случаях есть грабли

магия передачи pip'ов не каждому понятна - проверял "на своих". банальное "tail -f | grep pattern" может вызвать когнитивный диссонанс
exe файлы в таком случае будут большие, одновременно с этим все равно есть зависимости от NET/MONO платформы
вопрос сборки с версией библиотек - например ты слинковался с библиотекой, но проверял с версией N. А на другой платформе она оказалась M - потому что там другой автор её обновил. Нарвался тут недавно на линковку 1С платформы с kerberos библиотекой под Ubuntu "Та еще песня". История с icu.dll для 1С платформы под CentoOS тому также пример.

Пока писал - вдруг понял. Что компиляция скриптов в остальном мире применяется только для дистрибуции полученного скрипта в виде приложения, а приложение это Marketplace ;-). А для Marketplace нужна экосистема. Наверное это правильно - но уж сильно Enterprise.

В итоге у меня вопрос - @vsuh а зачем Вам переносимая сборка, чтобы на целевую машину не устанавливать oscript ? Может выходом будет удобная установка oscript на целевую машину ?

EvilBeaver commented 8 years ago

Original comment by Alexey Lustin (Bitbucket: allustin, GitHub: allustin):

@EvilBeaver меня несколько "пугает" это функционал, когда ко мне приезжает исходник пакета через opm, я могу его:

запускать
изменять локально
etc

А вот что делать с компилированным пакетом. Скорее всего это нужно для распространения, то есть дистрибуции. И тут начнётся "веселуха" с подписями авторов пакетов - я уже на chocko нарвался https://github.com/chocolatey/choco/wiki/Legal#distributions-aka-chocolatey-packages

То есть понадобится (пишу по памяти из Java мира и из Windows) для автора скомпилированного пакета:

подписать скомпилированный пакет сертификатом - чтобы exe считался доверенным
в движок вставлять работу с MD5 суммами, чтобы пакет можно было проверить на предмет того, что кто-то его не перекомпилировал вставляя вредоносный код.

Одновременно с этим

скомпилированный exe/bin необходимо будет вставлять в дистрибутивы MSI, Deb, RPM,

Может стоит это перенести в Enterprise версию ?

EvilBeaver commented 8 years ago

Original comment by Valery Sukhikh (Bitbucket: vsuh, GitHub: vsuh):

хотелось бы, чтоб вариант сборки выбирался параметром команды -make. Если это слишком трудоемко, я бы хотел вариант embedding, чтобы сборка была переносимой.

EvilBeaver commented 8 years ago

Original comment by EvilBeaver (Bitbucket: EvilBeaver, GitHub: EvilBeaver):

Issue #202 was marked as a duplicate of this issue.

EvilBeaver / OneScript

Компиляция модульных приложений #199