| 26 May 2025 |
 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 |
 @trofi:matrix.org | gcc does not require copyright assignment: https://gcc.gnu.org/dco.html | 12:49:35 |
 Tristan Ross | In reply to @emilazy:matrix.org
(not sure why we are doing more calls after everyone else on the team said it's not a good fit…) I know not everyone is available for calls which is why I made a doc. I think a mixture of async + sync is good. We can all be on the same page with the design doc while some of us are doing a call to pair up and blaze through things. | 20:42:22 |
| Tristan Ross | In reply to @trofi:matrix.org
Split GCC up similar to LLVM to accomplish this
I would suggest getting llvm-only bootstrap on linux first :)
An LLVM only bootstrap would take a lot of work that I'd be comfortable with after we have toolchain attrs | 20:50:44 |
| Tristan Ross | It would certainly be easier | 20:51:34 |
 John Ericson | Unless we drop GCC although, I think the GCC split up is something we need to do either way | 20:55:01 |
| Tristan Ross | Yeah, but I don't think we can drop GCC. | 21:04:07 |
| Tristan Ross | I consider it part of the "defacto standard Linux environment" | 21:04:27 |
 Grimmauld (any/all) | tbf, fhs-compliance is also part of the de-facto standard... | 21:04:57 |
| Tristan Ross | Kinda like GNU coreutils | 21:05:01 |
| Grimmauld (any/all) | nothing that can't be fixed given enough patches | 21:05:08 |
| Tristan Ross | In reply to @grimmauld:grapevine.grimmauld.de
tbf, fhs-compliance is also part of the de-facto standard... Well, we're exempt from that | 21:05:13 |
| Grimmauld (any/all) | i quite enjoy building the same thing with different toolchains - it shows where the flaky parts are, where assumptions are being made that might not hold | 21:06:11 |
| Grimmauld (any/all) | not having gcc would be fancy. | 21:06:24 |
| @trofi:matrix.org | would be nice not to have a cross-only llvm | 21:06:41 |
| @trofi:matrix.org | but having an llvm-only bootstrap would be a good test if it's easy to make a componentized-gcc bootstrap | 21:07:09 |
| @trofi:matrix.org | (i think it's very much not easy, but you already know that) | 21:07:33 |
| Tristan Ross | Yeah | 21:08:44 |
| Tristan Ross | I've already been looking into things to make it possible | 21:08:54 |
| Tristan Ross | One of the reasons why I've been working on fixing up pkgsLLVM | 21:09:11 |
| Tristan Ross | More things that work there, the better they'll work natively | 21:09:24 |
