-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
qt6.qtModule: support finalAttrs #352466
base: master
Are you sure you want to change the base?
qt6.qtModule: support finalAttrs #352466
Conversation
I believe @K900 expressed a desire to kill this off entirely; perhaps that would be better? Though the added complexity here doesn’t look so bad. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn’t notice the plugins change. This seems fine as a way to achieve that for now, but I’ll let @K900 take a look. I think we could avoid needing to change qtModule
by just giving qtwayland
a dependency on itself? But I guess overrides would act slightly differently.
Added to qtbase too |
a598e75
to
62526f1
Compare
7a58349
to
f33aa53
Compare
} | ||
|
||
passthru = { | ||
plugins = runCommand "${finalAttrs.finalPackage.name}-only-plugins" { } '' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be abstracted away in to qtModule and added with a hasQtPlugins = true
passthru = { | ||
plugins = runCommand "${finalAttrs.finalPackage.name}-only-plugins" { } '' | ||
mkdir -p "$out/lib/qt-6/plugins" | ||
ln -s "${finalAttrs.finalPackage}/lib/qt-6/plugins" "$out/lib/qt-6/plugins" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this. It's basically just here for wrapQtAppsHook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now yep unless others have more ideas for their use
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The desktop environment modules could install it? Since I assume they install full qtwayland
currently. Though I guess that would no longer be necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Desktop modules don't care if we pull in some cmake modules or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this either, could have been a separate output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qtwayland
exposes an API for writing Wayland compositors that at least one thing in the tree uses, so we do risk undeclared dependencies if we propagate all of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a risk we can take.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can move the symlinking directly in to the wrapper if this is not wanted, if we propagate just out as it currently is we might propagating a partially broken package
Please remember env bloat is bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just fix splitting $dev properly, and then have the hooks only propagate $out?
Only if there's a way to make the qt generated cmake files happy, last time I tried they blew up fantastically.
We used to patch cmake with for this purpose:
commit 16a7c7b31cef945a9e66e07283ed45cb8ff8e216 (HEAD -> nixpkgs)
Author: Nick Cao <[email protected]>
Date: Tue Apr 11 23:44:15 2023 +0800
cmake always export install file with absolute path
diff --git a/Source/cmExportInstallFileGenerator.cxx b/Source/cmExportInstallFileGenerator.cxx
index 195737b9fc..8d7d37e6a5 100644
--- a/Source/cmExportInstallFileGenerator.cxx
+++ b/Source/cmExportInstallFileGenerator.cxx
@@ -203,7 +203,7 @@ void cmExportInstallFileGenerator::GenerateImportPrefix(std::ostream& os)
this->IEGen->GetLocalGenerator()->GetMakefile()->GetSafeDefinition(
"CMAKE_INSTALL_PREFIX");
std::string const& expDest = this->IEGen->GetDestination();
- if (cmSystemTools::FileIsFullPath(expDest)) {
+ if (true) {
// The export file is being installed to an absolute path so the
// package is not relocatable. Use the configured install prefix.
/* clang-format off */
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the plugin symlinking directly to #352419
f33aa53
to
69632f4
Compare
So we can propagate plugins in `wrapQtAppsHook` without polluting the environment
69632f4
to
58712c3
Compare
Based on https://www.github.com/NixOS/nixpkgs/pull/331398
Overriding works as it should
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.