Remove target

RossSmyth commented

2025-10-02 23:53:06 +00:00

Contributor

WIP. Posting just to make sure people know this is something I'd like to do.

Context: https://matrix.to/#/!PvnunzXUk4Vm1CmKS4:auxolotl.org/$bOm6iaBpWbo-KRJgo7FUZdeFIv9StzRHxklbx7OQ23g?via=auxolotl.org&via=matrix.org&via=catgirl.cloud

Reasons:

Why should GCC inflict complication upon all of tidepool just because of its own architectural deficiencies?
Most other compilers are multi-target so it doesn't matter
Target is useless for 99.9% of packages and only leads to user confusion, especially since many compilers also call what would be host here "target".
Canadian-cross is not very well supported. GCC barely supports it, and is broken in many cases. Nixpkgs does not support it (regardless of what its API may imply) and no one has ever complained.

Plan:

Remove most target related things. No reason to have it.
Add configuration parameter on GCC that selects its target

What does this mean:

This basically moves target to be a GCC-specific artifact rather than an official parameter every package must endure the cognitive load of. This is because it is. Nixpkgs plans on dumping target in the future as well because of this. Or at least making it an alias.

If you want to create a compiler with a different target, then override GCC to do so. No need to pervade all of tidepool just for GCC.

WIP. Posting just to make sure people know this is something I'd like to do. Context: https://matrix.to/#/!PvnunzXUk4Vm1CmKS4:auxolotl.org/$bOm6iaBpWbo-KRJgo7FUZdeFIv9StzRHxklbx7OQ23g?via=auxolotl.org&via=matrix.org&via=catgirl.cloud Reasons: 1. Why should GCC inflict complication upon all of tidepool just because of its own architectural deficiencies? 2. Most other compilers are multi-target so it doesn't matter 2. Target is useless for 99.9% of packages and only leads to user confusion, especially since many compilers also call what would be host here "target". 3. Canadian-cross is not very well supported. GCC barely supports it, and is broken in many cases. Nixpkgs does not support it (regardless of what its API may imply) and no one has ever complained. Plan: 1. Remove most target related things. No reason to have it. 2. Add configuration parameter on GCC that selects its target What does this mean: This basically moves target to be a GCC-specific artifact rather than an official parameter every package must endure the cognitive load of. This is because it is. Nixpkgs plans on dumping target in the future as well because of this. Or at least making it an alias. If you want to create a compiler with a different target, then override GCC to do so. No need to pervade all of tidepool just for GCC.

RossSmyth added 2 commits 2025-10-02 23:53:07 +00:00

Remove target cause GCC is dumb 586d02fcb3

gcc: Remove target junk 005e477a1c

RossSmyth changed title from ~~WIP: Remove target~~ to Remove target

2025-10-02 23:55:35 +00:00

RossSmyth changed title from ~~Remove target~~ to WIP: Remove target

2025-10-02 23:55:37 +00:00

jakehamilton commented

2025-10-03 06:14:49 +00:00

Owner

I'm not sure I agree with this change. We will be tracking target as an option in all system compilers. Wouldn't it make more sense to have that as a standardized piece of information? Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently. If I drop gcc in deps.build.host then it should compile my program for the host platform. With these changes I would have to manually specify that or cross compilation wouldn't be supported at all.

I do see some benefit in simplifying the built package structure since we remove a whole layer by getting rid of target, but I am not sure it is worth it.

I'm not sure I agree with this change. We will be tracking `target` as an option in all system compilers. Wouldn't it make more sense to have that as a standardized piece of information? Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently. If I drop gcc in `deps.build.host` then it should compile my program for the `host` platform. With these changes I would have to manually specify that or cross compilation wouldn't be supported at all. I do see some benefit in simplifying the built package structure since we remove a whole layer by getting rid of `target`, but I am not sure it is worth it.

👍 1

RossSmyth commented

2025-10-03 14:52:47 +00:00

Author

Contributor

Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently.

This still does though? It's just that target will usually just be host. The only reason an individual target platform is needed is when canadian cross is done, which is not supported very well in GCC regardless.

> Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently. This still does though? It's just that target will usually just be host. The only reason an individual target platform is needed is when canadian cross is done, which is not supported very well in GCC regardless.

RossSmyth commented

2025-10-03 14:55:34 +00:00

Author

Contributor

Target is ONLY relevant when compiling GCC. When cross-compiling a normal package, for example Make, target doesn't mean anything at all. Make has no target, just a host. GCC has a target because it is built for a single target. This does not effect cross-compilation.

This would only effect if you wanted to do something like build a GCC that targets riscv to run on aarch64 on an x86_64 machine. Which if that even works that seems to be luck of the draw.

Nixpkgs does not support canadian cross and no one has ever complained, even though the API inplies it does. GCC's configure scripts generally don't based upon sniffing around.

Target is ONLY relevant when compiling GCC. When cross-compiling a normal package, for example Make, target doesn't mean anything at all. Make has no target, just a host. GCC has a target because it is built for a single target. This does not effect cross-compilation. This would only effect if you wanted to do something like build a GCC that targets riscv to run on aarch64 on an x86_64 machine. Which if that even works that seems to be luck of the draw. Nixpkgs does not support canadian cross and no one has ever complained, even though the API inplies it does. GCC's configure scripts generally don't based upon sniffing around.

👍 1

jakehamilton commented

2025-10-03 20:05:59 +00:00

Owner

@RossSmyth wrote in #31 (comment):

Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently.

This still does though? It's just that target will usually just be host. The only reason an individual target platform is needed is when canadian cross is done, which is not supported very well in GCC regardless.

It is common that GCC is built such that it outputs code for the parent package's host environment, not GCC's host environment. I am not talking about cases where all of build, host, and target are different. I am talking about cases where GCC's build and host are the same, but target is different as necessitated for cross compilation. You would have to pass this information manually everywhere you use GCC in order to support cross compiling packages. I think that is an anti pattern.

@RossSmyth wrote in https://git.auxolotl.org/auxolotl/labs/pulls/31#issuecomment-838: > > Having to manually set the target for cross compiling is something I wanted to avoid in Tidepool. I think it could be awesome if we just support cross compilation transparently. > > This still does though? It's just that target will usually just be host. The only reason an individual target platform is needed is when canadian cross is done, which is not supported very well in GCC regardless. It is common that GCC is built such that it outputs code for the parent package's host environment, not GCC's host environment. I am not talking about cases where all of build, host, and target are different. I am talking about cases where GCC's build and host are the same, but target is different as necessitated for cross compilation. You would have to pass this information manually everywhere you use GCC in order to support cross compiling packages. I think that is an anti pattern.

jakehamilton commented

2025-10-03 20:08:10 +00:00

Owner

@RossSmyth wrote in #31 (comment):

Target is ONLY relevant when compiling GCC. When cross-compiling a normal package, for example Make, target doesn't mean anything at all. Make has no target, just a host. GCC has a target because it is built for a single target. This does not effect cross-compilation.

This would only effect if you wanted to do something like build a GCC that targets riscv to run on aarch64 on an x86_64 machine. Which if that even works that seems to be luck of the draw.

Nixpkgs does not support canadian cross and no one has ever complained, even though the API inplies it does. GCC's configure scripts generally don't based upon sniffing around.

Target is relevant for the builds of single target compilers, but it is also relevant for hooks and potentially context. As much as I dislike having to juggle three platform identifiers I think this information is useful to propagate in a standard, implicit, supported way. Removing the ability to automatically handle cases where host != target adds a lot of extra work in every package definition.

@RossSmyth wrote in https://git.auxolotl.org/auxolotl/labs/pulls/31#issuecomment-839: > Target is ONLY relevant when compiling GCC. When cross-compiling a normal package, for example Make, target doesn't mean anything at all. Make has no target, just a host. GCC has a target because it is built for a single target. This does not effect cross-compilation. > > This would only effect if you wanted to do something like build a GCC that targets riscv to run on aarch64 on an x86_64 machine. Which if that even works that seems to be luck of the draw. > > Nixpkgs does not support canadian cross and no one has ever complained, even though the API inplies it does. GCC's configure scripts generally don't based upon sniffing around. Target is relevant for the builds of single target compilers, but it is also relevant for hooks and potentially context. As much as I dislike having to juggle three platform identifiers I think this information is useful to propagate in a standard, implicit, supported way. Removing the ability to automatically handle cases where host != target adds a lot of extra work in every package definition.

jakehamilton commented

2025-10-03 20:10:09 +00:00

Owner

I think it would be better to keep target as-is so we have as many options as possible to easily support all of these integrations. Being able to just drop GCC in as a dependency and have it work regardless of what platform information I am using is a large benefit.

vlinkz commented

2025-10-04 01:59:24 +00:00

Owner

@jakehamilton wrote in #31 (comment):

I think it would be better to keep target as-is so we have as many options as possible to easily support all of these integrations. Being able to just drop GCC in as a dependency and have it work regardless of what platform information I am using is a large benefit.

I'm actually split on this now, if we build a capability for gcc we won't have to worry about this, and for other compilers we'll need to pass another flag in anyways. So the only packages valid as a build.host dependency is gcc (and binutils unless you have --enable-targets=all flag).

Also if we do remove target, then we only need to have deps.build and deps.host, which should be easier for packagers to understand what goes where.

@jakehamilton wrote in https://git.auxolotl.org/auxolotl/labs/pulls/31#issuecomment-869: > I think it would be better to keep target as-is so we have as many options as possible to easily support all of these integrations. Being able to just drop GCC in as a dependency and have it work regardless of what platform information I am using is a large benefit. I'm actually split on this now, if we build a capability for gcc we won't have to worry about this, and for other compilers we'll need to pass another flag in anyways. So the only packages valid as a `build.host` dependency is `gcc` (and `binutils` unless you have `--enable-targets=all` flag). Also if we do remove target, then we only need to have `deps.build` and `deps.host`, which should be easier for packagers to understand what goes where.

jakehamilton commented

2025-10-04 06:39:58 +00:00

Owner

@vlinkz wrote in #31 (comment):

I'm actually split on this now, if we build a capability for gcc we won't have to worry about this, and for other compilers we'll need to pass another flag in anyways. So the only packages valid as a build.host dependency is gcc (and binutils unless you have --enable-targets=all flag).

Also if we do remove target, then we only need to have deps.build and deps.host, which should be easier for packagers to understand what goes where.

I am going to continue to think on this. Raito was also suggesting removing target entirely and also mentioned building a composite gcc package which had support for all systems.

@vlinkz wrote in https://git.auxolotl.org/auxolotl/labs/pulls/31#issuecomment-876: > I'm actually split on this now, if we build a capability for gcc we won't have to worry about this, and for other compilers we'll need to pass another flag in anyways. So the only packages valid as a `build.host` dependency is `gcc` (and `binutils` unless you have `--enable-targets=all` flag). > > Also if we do remove target, then we only need to have `deps.build` and `deps.host`, which should be easier for packagers to understand what goes where. I am going to continue to think on this. Raito was also suggesting removing target entirely and also mentioned building a composite gcc package which had support for all systems.

vlinkz commented

2025-10-04 15:55:32 +00:00

Owner

Tried testing this out a bit, and reshuffled some stuff to get part of gcc working. https://git.auxolotl.org/vlinkz/labs/src/branch/notarget

@jakehamilton wrote in #31 (comment):

I am going to continue to think on this. Raito was also suggesting removing target entirely and also mentioned building a composite gcc package which had support for all systems.

I personally would not want to go with composite gcc package soley for the purpose that it would take forever to compile

Tried testing this out a bit, and reshuffled some stuff to get part of gcc working. https://git.auxolotl.org/vlinkz/labs/src/branch/notarget @jakehamilton wrote in https://git.auxolotl.org/auxolotl/labs/pulls/31#issuecomment-879: > I am going to continue to think on this. Raito was also suggesting removing target entirely and also mentioned building a composite gcc package which had support for all systems. I personally would not want to go with composite gcc package soley for the purpose that it would take forever to compile

vlinkz force-pushed removeTarget from 005e477a1c to d6e8691e34

2025-10-05 17:24:42 +00:00

Compare

vlinkz force-pushed removeTarget from d6e8691e34 to c4eb0ec3c8

2025-10-05 17:25:15 +00:00

Compare

vlinkz changed title from ~~WIP: Remove target~~ to Remove target

2025-10-05 17:25:32 +00:00

austreelis commented

2025-10-05 19:00:08 +00:00

Member

We had a conversation on matrix about this topic that enlightened me a bit more about the tradeoffs.

I'm not 100% sold on the idea, but I have a clearer vision and I think there are clearly strong arguments in favor of this PR. I'm just worried that having to specify a target might be (too) contagious in practice, but I don't think we can really assess that before we get to package something like mesa.

And even then, it's still a question of compromising an API that touches all packages vs not all of them.

At the very least, I think it's worth exploring how a package set that's a bit bigger than what tidepool currently is looks with and without target, so while I'm currently cautiously in favor, I'd still want to wait. However I realize I don't know exactly how to judge when is the right time, for now.

We had [a conversation on matrix](https://matrix.to/#/!PvnunzXUk4Vm1CmKS4:auxolotl.org/$Hen4Lyg4JzxO_VB7QN2N-1L46atb00bIWne8BTmub-w?via=auxolotl.org&via=matrix.org&via=envs.net) about this topic that enlightened me a bit more about the tradeoffs. I'm not 100% sold on the idea, but I have a clearer vision and I think there are clearly strong arguments in favor of this PR. I'm just worried that having to specify a target might be (too) contagious in practice, but I don't think we can really assess that before we get to package something like mesa. And even then, it's still a question of compromising an API that touches all packages vs not all of them. At the very least, I think it's worth exploring how a package set that's a bit bigger than what tidepool currently is looks with and without `target`, so while I'm currently cautiously in favor, I'd still want to wait. However I realize I don't know exactly how to judge when is the right time, *for now*.

vlinkz merged commit be0d6bc0e1 into main

2025-10-07 03:46:53 +00:00

vlinkz referenced this pull request from a commit

2025-10-07 03:46:55 +00:00

refactor: remove target (#31)

r-vdp commented

2025-10-13 19:24:56 +00:00

First-time contributor

This broke nix --log-format multiline-with-logs build -f . packages.foundation.gcc.latest.packages.x86_64-linux.x86_64-linux.package for me, and people on matrix seem to have the same issue.

I looked into it for a bit, but I couldn't figure out how to fix it yet.

The error seems to occur during configure of nested libs in gcc, these are the last 500 lines in the build log: https://paste.sr.ht/~r-vdp/0d14ae5539c1ab4829f734557ed022ac1f38d82a

This broke `nix --log-format multiline-with-logs build -f . packages.foundation.gcc.latest.packages.x86_64-linux.x86_64-linux.package` for me, and people on matrix seem to have the same issue. I looked into it for a bit, but I couldn't figure out how to fix it yet. The error seems to occur during configure of nested libs in gcc, these are the last 500 lines in the build log: https://paste.sr.ht/~r-vdp/0d14ae5539c1ab4829f734557ed022ac1f38d82a

Rows
Columns

Remove target #31