Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux installation location conventions #23

Open
jochembroekhoff opened this issue Dec 17, 2019 · 4 comments
Open

Linux installation location conventions #23

jochembroekhoff opened this issue Dec 17, 2019 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@jochembroekhoff
Copy link
Contributor

The current CMakeLists.txt has the installation path fixed to /home/MMCE1.4, which is not desirable since it does not follow any convention and contains a version number.

It depends on the target distro where the actual files should be placed, so therefore it is common to have some kind of PREFIX variable (which generally falls back to something like /usr/local) that specifies the exact value of the installation root.

Being able to specify it using a variable is obviously preferable over patching the CMakeLists.txt at package build time.

I might do a PR for this sometime in the coming days.

@jochembroekhoff
Copy link
Contributor Author

This does however raise the issue of file permissions. When the binaries and assets are installed into a system folder (like /usr/share/...), it is not possible to write level records and settings.bin to disk without being root.
Having these files stored at user-local level, e.g. in ~/.local/share/marble-marcher-ce/..., is preferable since that does not require additional permissions.

@MichaelMoroz MichaelMoroz self-assigned this Dec 17, 2019
@MichaelMoroz MichaelMoroz added the enhancement New feature or request label Dec 17, 2019
@fgaz
Copy link

fgaz commented May 8, 2021

+1! I'd like to package this for NixOS, but right now I have to work around the lack of PREFIX, and there's still the settings.bin problem

@lboklin
Copy link

lboklin commented Nov 22, 2021

@fgaz This is tangential, but I created a nix derivation that appears to work, except that input doesn't work correctly (ball rolls to the left as if A was constantly held and the other keys don't seem to affect movement) but I don't know if that's related to the packaging or some other factor in my environment.

{ cmake, makeWrapper, stdenv, eigen, sfml, anttweakbar, glew, glm, openalSoft }:
stdenv.mkDerivation {
  pname = "marble-marcher-ce";
  version = "git-2021-09-01";
  buildInputs = [makeWrapper cmake eigen sfml anttweakbar glew glm openalSoft];
  prePatch = ''
    substituteInPlace CMakeLists.txt \
      --replace '/home/MMCE' $out
  '';
  postInstall = ''
    mkdir $out/bin
    mv $out/MarbleMarcher $out/bin/
    wrapProgram $out/bin/MarbleMarcher --run "cd $out"
  '';
  src = ./.;
}

Edit: The input issue is orthogonal to the packaging, as this works around the issue (so it must be some device being interpreted as a joystick):

diff --git a/src/Main.cpp b/src/Main.cpp
index 2ecbc5d..7614bf9 100644
--- a/src/Main.cpp
+++ b/src/Main.cpp
@@ -601,8 +601,8 @@ int main(int argc, char *argv[]) {
 						  (all_keys[SETTINGS.stg.control_mapping[RIGHT]] ? 1.0f : 0.0f);
 			}
 			//Collect gamepad input
-			force_y -= io_state.axis_value[SETTINGS.stg.control_mapping[JOYSTICK_MOVE_AXIS_Y]];
-			force_x += io_state.axis_value[SETTINGS.stg.control_mapping[JOYSTICK_MOVE_AXIS_X]];
+			// force_y -= io_state.axis_value[SETTINGS.stg.control_mapping[JOYSTICK_MOVE_AXIS_Y]];
+			// force_x += io_state.axis_value[SETTINGS.stg.control_mapping[JOYSTICK_MOVE_AXIS_X]];
 			 
 			InputRecord record = GetRecord();
 

Edit 2: The main issue is also relevant here, since the immutable $out path means that some things, e.g. screenshots, don't get saved.

@fgaz
Copy link

fgaz commented Nov 22, 2021

Yeah my package was similar... I never made a pr because unfortunately it doesn't work on my old/slow gpu so I couldn't test it :-/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants