Conversation
As it is this is only meant to help development. Example: nix develop -i -c sh -c 'cargo xtask build-streamer'
|
There is no point in patching Rust files. Instead you can achieve what you want using feature flags |
Can you pls elaborate further what you want? I should make a new feature flag for nix flake compile? |
|
You need to make a new cargo feature, let's say "nix", in alvr/server_openvr/Cargo.toml. This should look like |
2aa1cad to
934a525
Compare
zmerp
left a comment
There was a problem hiding this comment.
I don't use linux, let alone nix, but the changes don't seem to affect the rest of the platforms so I can approve. Maybe @The-personified-devil has any input, but otherwise we can merge
|
|
||
| [features] | ||
| gpl = [] # Enable for FFmpeg support on Windows. Always enabled on Linux | ||
| nix = [] |
There was a problem hiding this comment.
This needs a comment that it's for Nix the tooling not some general *nix stuff.
| inputs = { | ||
| self.submodules = true; | ||
| nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; | ||
| flakeUtils.url = "github:numtide/flake-utils"; # TODO use upstream nix utils |
There was a problem hiding this comment.
Why can't the upstream nix utils be used?
There was a problem hiding this comment.
What you mean by upstream nix utils? Somehow never heard of it.
There was a problem hiding this comment.
I've never seen the flake.lock package actually shipped in a repo? Is there a particular need for it, I'd like to avoid cluttering the repo base too much, it's already kinda messy.
There was a problem hiding this comment.
Yeah, It's pretty important, sadly, basically Cargo.lock for nix.
| NIX_CFLAGS_COMPILE = toString [ | ||
| "-lbrotlicommon" | ||
| "-lbrotlidec" | ||
| "-lcrypto" | ||
| "-lpng" | ||
| "-lssl" | ||
| ]; |
There was a problem hiding this comment.
What's going on here that this is needed? Is it that some of the rust libraries build the C library statically and this makes it be dynamically linked?
There was a problem hiding this comment.
I am pretty sure it does that there are in the binary.
| fn get_ffmpeg_path() -> PathBuf { | ||
| pkg_config::Config::new() | ||
| .probe("libavcodec") | ||
| .unwrap() | ||
| .to_owned() | ||
| .include_paths | ||
| .pop() | ||
| .unwrap() | ||
| .parent() | ||
| .unwrap() | ||
| .to_path_buf() | ||
| } |
There was a problem hiding this comment.
Also you're aware that there are a whole bunch of patches that we've done to ffmpeg, right? None of these are used when pulling it in from the system. Now I don't know how many of those patches were upstreamed in later versions (and I tried checking some time ago it's just really messy), but if you can't verify that, there should probably be some note in the flake that some encoding stuff may be broken under certain configurations when running through nix
There was a problem hiding this comment.
Oh 🦊, what are they? That kinda puts a spanner in the works.
| cargoLock = { | ||
| lockFile = ./Cargo.lock; | ||
| outputHashes = { | ||
| "openxr-0.18.0" = "sha256-v8sY9PROrqzkpuq3laIn2hPaX+DY7Fbca6i/Xiacd1g="; | ||
| "settings-schema-0.2.0" = "sha256-luEdAKDTq76dMeo5kA+QDTHpRMFUg3n0qvyQ7DkId0k="; | ||
| }; |
There was a problem hiding this comment.
Why's this needed? Perhaps we could fix it directly...
There was a problem hiding this comment.
Becouse theese do not contain a checksum in cargo.lock and nix currently does not support git hashes.
|
@makuru-org ping |
|
@jopejoe1 Since you already left a comment, does a nix file being provided actually have any impact on the package downstream, like is it automatically reused? Otherwise I'd probably strip this down to only behave as a devshell. |
Nope, nixpkgs does not make use of any nix files provied outside of nixpkgs.
Users still sometimes make use of nix files inside of projects to easily use the development version of packages. |
pong |
|
@makuru-org yeah, we could merge after the comments are resolved |
Continuation of: #2402.