-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Nix updates 2.3 #3258
Nix updates 2.3 #3258
Conversation
@haslersn wanna review ? I would like to have this in 2.3 soon, so we can official builds. |
8d798cd
to
bb5991f
Compare
19ceb4d
to
8e636ef
Compare
* Fixes lv2 wrapper so plugins show up again * Remove old binaries so makeWrapper does not create useless backups * Autodetect cmake buildtype and set type * Fix locale problems on none nix hosts * Remove useless imports and use "with" where possible * format sources with nixfmt * ingnore result* for sources * Allow cmake flags to be passed * wrap mixxx-test for running in ci environment * set QT_PLUGIN_PATH in case we run tests in a CI without proper paths
push packages to cachix Correctly report error codes. Run tests in travis dev shell don't fail if cache copy fails
Including the setup hook script does not work and only causes problems. Simply use nix-shell to run the wrapper in a reliable way. Add nodjs for eslint
Inform the user that this combination might break and how to mitigate it.
LLVM < 10.0.2 with glibc >= 2.31 don't link well with fast-math active. Add option to disable this optimization alone
I think nixpgs is for stable packages, but this config is for development versions and building from source. I think https://github.com/nix-community/NUR would be the proper repo for that. |
How do we continue here? We shouldn't tag 2.3.0 with a broken nixOS config. I think we have 4 alternatives:
Opinions? |
I'm in favour of #1, because the CI build with Clang compiler ensures compatibility, not only for NIX. |
We already ensure clang compatibility with the clang-tidy, clazy and macOS CI builds. |
The CI builds are not needed. NixOS users will notice any breakage when building locally and could then file a PR. Why should we maintain CI builds that affect only very few users, are unmaintainable for most of us, and are not needed for any official release? We also don't host CI builds for other Linux distributions. |
Correct, we already have one CI build for each compiler suite (GCC, Clang, MSVC). We cannot test all possible combinations including different versions, platforms, CPU architectures, ... |
I'd prefer 4, but I'm also okay with 3 or 2 if most others disagree. If we chose 1, all PRs with failing nixOS builds are essentially blocked until @poelzi reviews them and contributes a fix. Or we ignore if the nixOS CI fails, which makes them kinda pointless. |
I vote for 2 or 3. If we decide for 2, I would prefer to cut out unrelated changes into single PRs. |
This PR is marked as stale because it has been open 90 days with no activity. |
Can we close this stale PR now? Our main build tool is cmake and we don't have the power to maintain another build script of 397 lines. |
This PR is marked as stale because it has been open 90 days with no activity. |
Currently going through old & stale PRs in an effort to reduce the number of open PRs. |
Yes, let's close this and than also decide for |
These is a backport of #3174 to 2.3.
It fixes all issues I found so far in the derivate.
This will allow us to deliver up to date derivates through cachix to the enduser.
This branch now has working travis for nix and runs all tests.