Инсталляция окамла под виндой
Занимаюсь типичным местным вудуизмом - ставлю прогу из инсталлятора в виртуальной машине, проверяю, что она вообще работает, а потом пытаюсь ее запустить в стиле "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
В смысле, что прога, dll которой лежат у нее в папке, в большинстве случаев не сломается если другие проги обновятся вместе со своими версиями этих же dll.
no subject
no subject
no subject
если писать свой гуй и использовать direct hardware access, это уже встроенная система получается, виндовс не нужэн.
no subject
no subject
Поставленный рантайм питона в винде был обновлен. Старый софт отказался работать. Юзеры предали анафеме разработчиков.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
шарп уже опять на инишках
no subject
no subject
no subject
no subject
А вот конфиги типа конфигурирования каких-то алгоритмов софта - это должно лежать около программы, можно таки даже в .ini, одни на всех.
no subject
можно таки даже в .ini, одни на всех.
По-хорошему, должны быть дефолтные, общесистемные (перекрывающие дефолтные) и юзверские (перекрывающие общесистемные и дефолтные). С возможностью запретить переопределение дефолтных юзером.
no subject
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