Инсталляция окамла под виндой
Занимаюсь типичным местным вудуизмом - ставлю прогу из инсталлятора в виртуальной машине, проверяю, что она вообще работает, а потом пытаюсь ее запустить в стиле "xcopy deployment", т.е. копирую инсталлированную папку программы на другой комп и изучаю, что нужно для запуска.
Вообще подобная практика, конечно, сомнительна, особенно в свете толкаемых
zelanton уверений, что во низкоуровневых внутренностях прикладным программистам разбираться запрещено. Но таким образом я набрал уже приличную коллекцию виндовых (а особенно портированных с линукса) программ, которые переживают без переинсталляций любые пертурбации с компами, переустановку виндов и железа, переезды между разными рабочими местами, носимые винты, итд
Так вот в окамле в таком случае оказалось, что там, мало того что пути пишутся в реестр, так еще и переменная окружения используется для поиска либ. С ходу не вижу, почему бы не сделать при отсутствии оных переменных и ключей реестра использование дефолтных значений вроде "папка_с_exe\..\lib\".
Т.е. что под виндами, что в линуксе авторы софта как-то очень уж надеются на стандартную инсталляцию. В некоторых особо сложных случаях это допустимо, но я обычно стараюсь делать прогу запускаемой, даже если психи ее просто скопировали, так проще жить как самому, так и пользователям.
Вообще подобная практика, конечно, сомнительна, особенно в свете толкаемых
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Так вот в окамле в таком случае оказалось, что там, мало того что пути пишутся в реестр, так еще и переменная окружения используется для поиска либ. С ходу не вижу, почему бы не сделать при отсутствии оных переменных и ключей реестра использование дефолтных значений вроде "папка_с_exe\..\lib\".
Т.е. что под виндами, что в линуксе авторы софта как-то очень уж надеются на стандартную инсталляцию. В некоторых особо сложных случаях это допустимо, но я обычно стараюсь делать прогу запускаемой, даже если психи ее просто скопировали, так проще жить как самому, так и пользователям.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
В смысле, что прога, dll которой лежат у нее в папке, в большинстве случаев не сломается если другие проги обновятся вместе со своими версиями этих же dll.
no subject
Поставленный рантайм питона в винде был обновлен. Старый софт отказался работать. Юзеры предали анафеме разработчиков.
no subject
no subject
no subject
no subject
no subject
шарп уже опять на инишках
no subject
no subject
А вот конфиги типа конфигурирования каких-то алгоритмов софта - это должно лежать около программы, можно таки даже в .ini, одни на всех.
no subject
no subject
no subject
если писать свой гуй и использовать direct hardware access, это уже встроенная система получается, виндовс не нужэн.
no subject
no subject
no subject
можно таки даже в .ini, одни на всех.
По-хорошему, должны быть дефолтные, общесистемные (перекрывающие дефолтные) и юзверские (перекрывающие общесистемные и дефолтные). С возможностью запретить переопределение дефолтных юзером.
no subject
Чтобы было типа "ставишь пакет А, зависящий от пакета Б, но пакет B зависит от другой версии пакета Б и возникает конфликт"? Зачем мне это счастье?
А то я вот ставлю окамл с зависимостями от tk84, а у меня уже стоит питон с зависимостями от tk85, но они друг друга не видят и друг другу никак не мешают, тупо две никак не связанные независимые папки.
no subject
А количество гуеинсталлеров считающих что "мы ставимся на чистую систему" и имеющий привычку срать в /usr/lib или /system32 или (как там оно на винде зовется) будет зашкаливать за 9000
no subject
no subject
no subject
У белых людей такого уже давно нет, все мажорные версии лежат в отдельных слотах. Т. е. как бы и версия того же пакета, но конфликтов нет, поскольку раскрывается в разные файлы. А симлинки на дефолтные версии отдельным скриптом конфигурируется.
no subject
no subject
no subject
no subject
no subject
no subject