-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
our gcc-unwrapped expression is illegible #242336
Comments
The CompilerIn his blog, @trofi mentions the enormous distance between what we have right now, and the "ideal situation" of
The lists of flags and variables (
Note that you can do the above with zero builds. Those lists should be defined by a simple (but probably quite long) chain of
Specifically, I think we need to:
The Target Libraries@trofi, one thing you called attention to in particular is the way we set
I don't really like either of those options but I can't think of any others. Any ideas? |
I think it's important to keep in mind (or even better - document them somewhere) the assumptions, the requirements and the principles of solving complex problems. I see I have a few requirements in my head that don't match with current
With this context I don't think it matters much if you move target libraries out to a separate derivation (and make the build even more deviating from upstream) or use a booter Both will probably increase amount of |
@trofi So I think once we are finally per-component it really will all be better. I know that sounds like some "after the revolution it will be utopia" sort of thing, but i think the current situation of:
really is an awkward middle ground and this is where the pain comes from. Yes, building GCC per component is not what upstream has in mind, but Exherbo has done it for years (see #132340) and I think it is at least stable. Looking at their code, libgcc is by far the weirdest; the others are pretty simple. Ironically, libgcc is the only we've managed to replicate their way so far. I have been delaying on #132343 far too long, but I think after 23.11 @amjoseph-nixpkgs and I will pair to try to finish it off --- hold us to it!! With that done
Furthermore, with now two distros going this route, I think we'll have a decent shot at getting upstream to better care about this case. And I fully intended to get any patches etc. submitted upstream around. In particular, no more making the mistake I did of leaving it for later and never getting around to it with the binutils split, I promise! |
Hrm, I'm not sure why the merge of #249707 didn't auto-close this. |
@Ericson2314 I hope you'll succeed :) I'll refrain from specific comments. |
@trofi recently blogged (yay rss) about the fact that our gcc expression is... extremely complex. That article gave me more perspective on this comment.
I'd like to start a discussion about trying to get our gcc expression into a state where people can actually understand wtf it is doing. Since we sadly do not have a mailing list anymore, I guess a github issue is the right venue for
long-form discussion.
I'd like to try to keep this focused on simplifying the unwrapped gcc (pkgs/development/compilers/gcc).
Our `cc-wrapper` is extremely complex as well, but there are things it needs to do (like [`NIX_CFLAGS_COMPILE`](https://github.com//issues/79303#issuecomment-720647170)) that look ugly but exist for reasons that took the Nix project a long time to learn. It could use simplification too, but I think the issues there are different and more challenging. However moving things out of `pkgs/development/compilers/gcc` and into the `cc-wrapper` might be part of simplifying `gcc-unwrapped`.The text was updated successfully, but these errors were encountered: