[RFC 0037] add x86_32 #37
Conversation
|
This pull request has been mentioned on Nix community. There might be relevant details there: https://discourse.nixos.org/t/i586-cross-compiling-ambiguous-i686-use/1482/8 |
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| - i586 and predecessors are already uncommon and use continues to diminish. |
There was a problem hiding this comment.
The usual issue we have with things like this (minority architectures/platforms) is that someone strongly motivated will propose something, do a lot of cross-cutting work to support it across all of nixpkgs, then lose steam and then the maintenance burden of all the cross-cutting changes falls upon the community, which largely lacks the time/resources/motivation/expertise to maintain it.
So I'd phrase the drawbacks in terms of maintenance burden and degree to which this support can be confined to a small region of nixpkgs. The more "compact" such support is, the easier it is for me to believe it's practical to put into nixpkgs. If it's straggly (all sorts of random switches in all sorts of random builds) it becomes a much harder sell to me. I've already been on the fence about the cost/benefit ratio of our i686 support, not because I don't want more people to benefit from Nix, but because being the only maintainer of a niche platform within a niche package manager is not fun and leads to burnout when everyone's patches are constantly breaking your stuff. The biggest example we have of this is macOS, which I think has achieved "critical mass" (to the point of being sustainable), often had me questioning it along the way. Other Linux users probably still do question the value of the occasional .isDarwin switch floating around their packages that they can't test and can't engage meaningfully on.
|
My top-level comment beyond the long one I wrote above is that this seems like a pretty hard sell that hasn't really convinced me. I'd be in favor of more precise language around our existing tl;dr: 👍 on precise naming, 👎 on support for more 32-bit intel platforms. |
|
In practice I do not forsee any i[345]86-specific hackery landing. 90% of the stuff I tried on i586 just worked, and the remainder lacked generic cross compile support that would be needed for any cross target. I do expect some correction of precision errors ( |
|
Are there any CPUs below i586 level manufactured today for PC-acrhitecture applications? I think if the entire question is likely to be just about a few cases where target architecture needs to be given to the build, it might be not that bad; adding an architecture unlikely to ever be useful with Nix (i386) still sounds weird. Maybe a good question is also the following: how much needs to get into the mainline Nixpkgs to make an overlay significantly less painful? |
|
@copumpkin on the contrary I think the only RFC-worthy issue is the breaking change of fixing the naming. We already parse far more ARM variants than we test (with next to no special cases within 32-bit ARM), and this hasn't caused any problems or complaints to my knowledge. I don't see why this would be any different. |
|
I've made the RFC and implementation PR more conservative. Implementation is little more than allowing |
|
My bad via breaking change. |
|
@goertzenator Are you ready for us to open nominations for a shepherd team as per the new RFC process? |
|
The implementation PR was already merged, so I'm not sure what should happen. Maybe this topic wasn't quite RFC worthy to begin with, but there is useful content and discussion here for reference purposes. |
|
Heh, OK. For now let's close it, if there's a community decision to be made we can reopen. |
Add support for i386-i586 cpus.