Add initial nix build support #156
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nakato
force-pushed
the
nixflake
branch
4 times, most recently
from
12d8250 to
adcf3c0
Compare
|
I haven't touched the SBC I was checking this on in a while as I stalled out on a panic occurring in u-boot. That's obviously unrelated to this work, but I don't want to wipe my SD card and loose the ability to reproduce the issue. To summarise the current state as the opening is pretty long: |
Merged
This currently lacks support for dev-shells, though you can run `nix develop -L .#packages.x86_64-linux.openDsh_dash` to get a configured environment for building a single package. Dash can be built with `nix build -L .#packages.x86_64-linux.openDsh_dash` Protobuf is pinned as later versions require building with C++ 17 or greater. -std=c++17, or editing CMakeLists.txt `SET(CMAKE_CXX_STANDARD 17)`. Rather than downgrading openssl, I'm taking a patch for it. We could easily pin it by referencing openssl_3_0 instead of simply "openssl". Versions don't bump further until the lockfile is pushed forward.
To function openauto requires OpenGL, specifically EGL on wayland.
This is problematic with Nix as OpenGL drivers are managed in a impure
way under NixOS, with them existing at /run/opengl-driver. That's not
the case with Raspberry Pi OS (Debian) as they exist at
/usr/lib/aarch64-linux-gnu, along with all the other system libraries.
There's no easy way to get the system libraries to work on Debian. The
best course of action would be to copy a few libmesa libraries into
~/.opengl-driver, patchelf their *rpath* to the system path, and point
LIBGL_DRIVERRS_PATH to /usr/lib/.../dri. But, we run into an issue
where libLLVM as compiled by upstream has an RPATH of ${origin}/../lib,
and that messes everything up as that turn /usr/lib/aarch64-linux-gnu
into /usr/lib/lib, and child libraries then fail to load.
"nixGL" is a tool that will let you run commands from nix that require
OpenGL on non-NixOS systems, but it's a runtime evaluation, which isn't
compatible with a car environment of
(Offline || Metered Networking) && Instant On.
Nvidia GPU's won't work out of the box, and that's probably not what
people use in a car, so with Nvidia use base dash package and run it
with nixGL.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm not sure why install.sh builds bluez from source rather than taking the system packaged one, but it's a good example of one of the ways nix will be really useful here. If we needed to change bluez, we can do so without conflicting with the system bluez that is installed.
The same goes for OpenSSL. While I've elected to take a patch to allow the use of the latest OpenSSL, the references to OpenSSL could easily be changed from
openssltoopenssl_3_0.Protobuf is pinned, as newer version require building with C++ 17 or greater by editing CMakeLists.txt
to contain
SET(CMAKE_CXX_STANDARD 17).Currently, this lacks a devShell, and I'd like to leave that for a future followup as it's not something I have much experience with currently. Build environments for individual packages can be realised by requesting one for the package in question.
nix develop -L .#packages.<SYSTEM>.<PACKAGE>, and is mostly useful to run through nix build phases, rather than being a generic dev environment.Dash can be built on x86_64 with,
nix build -L .#packages.x86_64-linux.openDsh_dash_nonnixos, and a symlink to the store location will be at./result.It might make since to move the package declarations of aasdk and openauto to the respective packages as it would likely make overriding them locally easier as it would be possible to pass --override-input with a path during
nix flake lock, but that also complicates the handling of qtgstreamer and h264bitstream, and makes it more difficult to see how this all works together, so it's probably also better as a change to be made when that added complexity comes with a clear benefit.For non-NixOS, openDsh_dash_nonnixos is the package to use as it's a script that is wrapping the dash executable to include opengl drivers from nixpkgs.
I tested this with the latest Raspberry Pi OS (bookworm) on a RPi4 4GB, and launched dash from a Sway (Wayland) environment.