Oooooh, I get redoconf now. Which probably means I've missed something crucial that'll bite me in 5 minutes.

The trick with all these tools is they do much less than you think, but also much more than you think. Hope this helps.

redoconf is my personal experiment, much more annoyingly complex than core redo. It seems to be useful to us but any design comments you have are probably helpful :)

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?"

Yeah. That part is either genius or horrible, I can't quite tell which. :)

Once I got it, it's pretty nice. I haven't poked at the machinery that makes all that stuff go, but when it goes, it's a nice way of doing multi-target builds.

The mahinery itself is not that complex: there's an out/{target}/default.do that just sets some environment variables, looks for relevant .od files, and runs them.

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.

That's in allconfig.do. It unsets ARCH for the one target where $native == $ARCH. This marks it as not a cross compilation. But I can't remember if or why that's actually necessary anymore. Oops.

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?

I definitely do like 'b'. The way 'a' works is something that I can't wrap my hear around yet though. But didn't have much time to dig more into that yet.

Would you share your go.rc for some inspiration? :)

Oh yeah, should move that into core redoconf. I was just keeping a private version at first so I could change the semantics without feeling guilty. But it seems to have settled down.