@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`.
@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`.