Open IainSteers opened 5 years ago
Thanks for filing this! The configuration looks reasonable to me. I think it would be most natural for the os-arch build to use any globally specified environment
values first, and then overlay any os-arch specific values on top of that (so if the same key is specified in both, then the os-arch level value will overwrite).
One possible concern I have is that I believe the os-arch
struct is used pretty extensively throughout, and conceptually represents just the OS/arch combination. If we do proceed with this approach, then I think we should define a new struct that wraps the OS/arch struct and then use that struct in this section of config (and in the places in the codebase where it makes sense).
Also, a few questions about the CC
and CXX
values:
CC
and CXX
path values? It seems like this would be pretty dependent on environment... Are the values in the CI build environment generally the same as the value in the local environment?Just want to make sure that the problem space is fully understood before we move forward on an implementation.
Hey Nick,
Thanks for the suggestions, agreed on your concerns re: the wide consumption of the OSArch struct.
In response to your questions:
/usr/bin/mingw-w64-gcc
or /usr/bin/osxcross-gcc
Thanks. So for point (2), that means that the Linux container image contains the osxcross-gcc
binary and uses that for the darwin builds?
Yeah that's correct. The linux image has cross-compilation toolchains for windows, linux and darwin
Got it, that makes sense. Given all of this, I'm in sync with moving forward with the original proposal (as long as the environment information for os-arch
is added in a scoped manner)
We have a couple of cross-platform CGo projects that require custom
CC
andCXX
specified per os-arch combination.This is problematic because distgo currently only supports environment specification at the build level. Currently we're working around this by using multiple dist-plugin files and passing them to godel directly with the
--config
flag.This isn't great because then the manifest and metadata files in the dist aren't entirely accurate, and it's hacky in CI.
As a solution, I'm envisaging something like: