Det said all that is needed is to simply unpack some pre-built zip into a folder..
if you skip all this package/libs mess and provide all in the same place it should work same way as on windows he said.
proposal for rules of deprecation of Lua API stuff
Moderator: Moderators
Re: proposal for rules of deprecation of Lua API stuff
Problem is this zip det is thinking of is currently akin to a flying unicorn.
On a sidenote, could you explain how package management is a mess as opposed to everything installing anywhere?
On a sidenote, could you explain how package management is a mess as opposed to everything installing anywhere?
Re: proposal for rules of deprecation of Lua API stuff
well, if you think of spring as a package, then, no, i don't think you can have multiple global installs, and it also wouldn't be right to ask for admin rights whenever you join a battleroom that has a new engine
but, if you imagine engines to be much like maps/mods, then they can be downloaded (by the lobby client) to a user dir (f.e $HOME/.spring/engine)
you would only be installing lobby clients as packages, such as springlobby/notalobby/$LINUX_WORKING_LOBBY and they would be the ones downloading the engine
but, if you imagine engines to be much like maps/mods, then they can be downloaded (by the lobby client) to a user dir (f.e $HOME/.spring/engine)
you would only be installing lobby clients as packages, such as springlobby/notalobby/$LINUX_WORKING_LOBBY and they would be the ones downloading the engine
Re: proposal for rules of deprecation of Lua API stuff
Yes gajop, but there currently is nothing any lobby could download on a given distro extract it somewhere so it would just work.
Re: proposal for rules of deprecation of Lua API stuff
I know, but btw, we may want to skip the entire part of distro-based packaging and have only one linux 'package' per release. The reason is most package systems do dynamic linking, and that would be a problem in a multi-version engine (f.e an new engine release requires a newer version of a package which is backwards incompatible with an older one).
Is full static linking a possibility? Or could it be possible to link only a few things, that hopefully never change? What would be the size & compatibility repercussions - will stuff work when a new X comes out f.e?
Is full static linking a possibility? Or could it be possible to link only a few things, that hopefully never change? What would be the size & compatibility repercussions - will stuff work when a new X comes out f.e?
Re: proposal for rules of deprecation of Lua API stuff
Full static linking is impossible, because one needs to use at least the system's ogl lib. Jk made some recent headway in getting an "as static as possible" build, he can say more to the matter.