| 26 May 2025 |
 emily | I think libc++ passes one and Rust passes another and so on and so forth | 11:37:20 |
| emily | autotools treats -macos as classic macOS IIRC, or at least -macos9 maybe | 11:37:39 |
| emily | my suspicion was that -macosx would be more palatable to the non-Apple/LLVM ecosystem, but it does have the drawback that we're standardizing on a name that has been out of date for many years | 11:38:05 |
 Randy Eckenrode | Note that the default target would still be <arch>-apple-darwin. The translation would happen in the wrapper when invoking the unwrapped compiler. | 11:42:58 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
that only applies to old autotools versions right? aarch64-darwin unconditionally includes the hook by default in its stdenv. | 11:43:59 |
| emily | I see | 11:43:59 |
| emily | then I doubt that'd cause issues, but to me it'd be nice to use it as the actual target. | 11:44:12 |
| emily | since it is more accurate and precise | 11:44:29 |
| emily | I just gave up because I didn't feel like fighting autotools when the freeze was in sight | 11:44:37 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
I think it would be possible, but I think I would want to upstream support for it to autotools Do they still require copyright assignment? | 11:44:42 |
| emily | not sure. some GNU projects stopped doing that. | 11:44:53 |
| emily | I didn't realize this. but surely upstream does support it these days right? | 11:45:06 |
| emily | I guess in that case it would be fine but I'd still prefer not to patch autotools in ways upstream explicitly rejects. we could just ask them about it I suppose. | 11:45:26 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
we'd have to teach the GCC/binutils build about macosx* versions instead of just darwin* I think… or just get LLVM Flang packaged and give up on GCC on Darwin since we're already applying a ten billion line patch by one guy just to get it building… AFAIK he’s upstreaming his work. It’s just taking a while. We should probably apply the patch on both platforms …. | 11:45:42 |
| emily | we could just apply it unconditionally, it shouldn't break cross now… | 11:46:42 |
| emily | but that's a pretty huge GCC patch to apply | 11:46:48 |
| emily | at least it doesn't touch other platforms really | 11:47:00 |
| emily | (I believe he's a GCC committer?) | 11:47:07 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
oh I should also say: even Apple and LLVM are inconsistent about whether it should be -macos14.x or -macosx14.x. I forget which one is canonical. I would go with whatever Swift does because AFAIK it only supports one wayS | 11:49:59 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
oh I should also say: even Apple and LLVM are inconsistent about whether it should be -macos14.x or -macosx14.x. I forget which one is canonical. * | 11:50:03 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
I just gave up because I didn't feel like fighting autotools when the freeze was in sight My goal is to align what we pass to the unwrapped compiler to what Swift is doing and relax the target check because otherwise very build causes tons of log spam. The wrapper can accept all the variants and do the mapping if that’s what keeps various build systems happy. | 11:52:09 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
I just gave up because I didn't feel like fighting autotools when the freeze was in sight * | 11:52:22 |
| emily | fair enough, I agree if we have to choose between the two then matching Swift is good. I expect macosx has wider compatibility anyway. | 11:52:39 |
| emily | do you want my diff from when I was trying -macosx and when I was trying -darwin<kernel version>? | 11:53:06 |
| emily | you could combine those and if you teach a hook to teach autotools about it you can probably get a lot further testing it than me. | 11:53:20 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
do you want my diff from when I was trying -macosx and when I was trying -darwin<kernel version>? Sure. | 11:58:12 |
| Randy Eckenrode | In reply to @emilazy:matrix.org
fair enough, I agree if we have to choose between the two then matching Swift is good. I expect macosx has wider compatibility anyway. Especially if we adopt Swift Build to replace xcbuild. | 11:58:35 |
| Randy Eckenrode | But boy does that thing have a ton of impurities …. | 11:58:55 |
| emily | https://github.com/emilazy/nixpkgs/commits/push-vsxoyyworlsz is including the Darwin kernel versions. IIRC I ran into issues with this that made me postpone it to post-release but I forget where. https://github.com/emilazy/nixpkgs/commits/push-rkpovppmolzv is using macosx. I didn't try combining the two since macosx failed so early in bootstrap, but I imagine if you get macosx working then adding the version would be easy.
you probably know this, but for macosx* the suffix is the actual macOS version, as opposed to darwin*'s kernel version. that's convenient since we can just append the minimum version directly. LLVM knows how to translate between the two. OTOH I think there are a fair number of build systems that just match on darwin* for version, like the GNU toolchain certainly, so those will need teaching about it. one option is probably just to have a gnuTarget or whatever so that we can mangle the targets for those things. the idea of having one single triple is unworkable anyway. (autotools itself just doesn't care about the version suffices for Darwin I think, though maybe some extension modules for it do.)
| 12:19:03 |
| emily | we might want something in the kernel struct for if isMacOS then "darwin" else parsed.kernel.name since it seems to come up a lot, but OTOH a lot of those instances already have other special cases that I just extended, so maybe it'd be better to have go.* and node.* and stuff like we have rust.*… | 12:20:39 |
