Skip to content

Conversation

@voidus
Copy link

@voidus voidus commented May 2, 2023

I can't be bothered to remember adding nixGL and I'm sure I'm not the only one.

@voidus voidus force-pushed the nixglwrap-readme branch from 8de42a4 to b34c49a Compare May 2, 2023 21:42
@voidus voidus force-pushed the nixglwrap-readme branch from b34c49a to 5cdeaed Compare May 2, 2023 21:57
paths = [ drv ];
buildInputs = [ pkgs.makeWrapper ];
postBuild = ''
# This will break if wrapProgram is ever changed, so fingers crossed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are not using wrapProgram directly?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, there's no way to tell makeShellWrapper to make an actual wrapper in the sense that nixGL wraps stuff, so I overrode it with what we need here.
I still wanted to use wrapProgram though because it has some logic to correctly deal with multiple layers of wrapping.
If you think it would be better I'll inline it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double wrapping as you describe it should be avoided as much as possible as it is very hard to get right. I think it would probably be an idea to modify the existing wrappers to fit your usecase to create one wrapped binary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be misinterpreting that, but my reading of the code is that this is what wrapProgram is for. I'm actually wrapping mixxx twice myself (nixGL and adding LD_LIBRARY_PATH for jack), and I'm pretty sure the package adds another wrapper itself.

This is obviously not optimal, but it makes things somewhat composable.

Anyways, I don't think we really have something to argue about here. I just found this solution for myself and thought it would be valuable to share.
I'm personally a bit hesitant to propose using wrapProgram directly because it will not work on packages which use a wrapper internally.

It's your decision what to put in the readme, I'm just offering a suggestion from my personal point of view.

Copy link
Member

@Artturin Artturin Oct 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, there's no way to tell makeShellWrapper to make an actual wrapper in the sense that nixGL wraps stuff, so I overrode it with what we need here. I still wanted to use wrapProgram though because it has some logic to correctly deal with multiple layers of wrapping. If you think it would be better I'll inline it.

You should be able to do it the same way that electron programs are handled in nixpkgs

makeWrapper ${electron}/bin/electron $out/bin/${pname} \
  --inherit-argv0 \
  --add-flags $out/share/${pname}/resources/app

Also please use makeBinaryWrapper, inherit-argv0 works better with it AFAIK.

Co-authored-by: Sandro <[email protected]>
@dyfrgi
Copy link

dyfrgi commented Jul 5, 2025

Home Manager now has this sort of wrapper script. I could still see it being useful to have here for users who aren't using home manager, though, like dev shells or builds on non-NixOS. How similar is this approach to that one? Could we just adopt it here and then have HM call the wrapper from this package? Presumably HM would still handle making it into a no-op in cases where nixGL is not set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants