[RFC] avoid unnecessary rebuilds #2141
Open
+38
−21
Conversation
This file contains hidden or 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
gnome-shell was rebuilt on every theme change to: 1. apply a patch 2. replace a file with the new theme. Only (2) needs to be done on each theme change, so it makes sense to have a separate derivation for (1). This way, the actual C code in gnome-shell needs to be built exactly once independent of the applied theme.
stylix-automation
bot
added
topic: nixos
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
It seems to me that theme changes cause building large things that are often not necessary rebuild for every theme change. I made a couple of changes to illustrate how I think they can be, at least in part, avoided without disabling the theming.
gtksourceview
This example is simple: It only adds a file to the derivation. I see little point in building the C code in order to do that; instead we can just have a derivation that takes the vanilla
gtksourceviewas input and adds the style.gnome-shell
This one is more tricky, and I'm not sure I have been able to get any real-world benefit out of this because of upstream dependencies. The original override here
(1) obviously entails an unavoidable rebuild, but, again, it shouldn't be necessary to do it for each theme change. (2) can be done without rebuilding the code.
Now, apparently the gnome-shell derivation ends up anyway somehow depending on gdm; and, obviously, these being overlays, a change still triggers a full rebuild everywhere downstream.
So, unlike the gtksourceview case where I think we genuinely can avoid having the C code rebuilt ever, I'm not sure if that's the case here, at least given the current mechanisms.
Then, I admit it's also unclear to me to what extent these need to be changed by patching the derivations instead of standard runtime theming mechanisms. Apparently the big offender here is gdm, which cannot be themed in runtime. But why gtksourceview? I see that in my build it's pulled in by virt-manager, and it just feels profoundly strange that I need to rebuild virt-manager if I change my color theme.