The key insight I was missing for a while is how .od files execute from an out/ directory, with a pointer to the source tree. Once I had that, they all started making sense, as did "why does `redo out/x86_64-linux/foo` work?"
I was thinking of the ./configure machinery, which seems to define a bunch of variables in *.rc files.
One of those surprised me (GOARCH is not set on the native architecture), which means I need to learn more and reduce my surprise.
It's the rc bits I'm not following. allconfig.do declines to pass --host=... to configure on the native platform, which afaict turns into ARCH not being declared when go.rc.od runs. That's the link I'm currently missing.
redoconf/configure sets ARCH to the value of --host=, in order to mirror some of autoconf's slightly funny command-line syntax and make it seem a bit more familiar.
Try 'redo -x out/native/rc/go.rc' to see a complete trace of how each variable gets set.
I see you guys talking about redoconf for Go. I'm still struggling a bit to understand if redoconf could be useful for non C/C++ projects at all. What could I look up to get more idea about it? Or I just need to re-read the cookbook until I get it? :)
Fundamentally redoconf is a framework for a) detecting things about your OS or cross compiler, and b) building output files in a separate tree from your source files. If you don’t need either of those, redoconf probably doesn’t add much :)
We’re not *really* using it for just go. If we wanted that there would be easier ways (probably without redo at all). But once we started mixing packagers, nsis installers, swift programs and simulator tests, code signing, etc, it’s more useful.
I definitely needed to re-read cookbook couple more times to get it :) Building multiple languages for multiple platforms is something that I'm interested in + some code generation and some tools around. I guess redoconf could help me with that vs. just redo?