On 4 March 2015 at 17:54, Tianon Gravi <[email protected]> wrote: > Doesn't the "go" binary support co-installability and use via the > "-compiler" flag too? How will that play into this proposal?
After spending some time with the gccgo-5 package in experimental (that now has these alternatives baked in...), I'm actually more -1 on using alternatives for this now. The "go" implementation bundled there is not fully-baked. For example, using "go get" to download a project didn't bother downloading the dependencies like it should, thus causing the build to fail really hard with a screen-full of errors. Worse yet, I tried building the newly-merged-upstream[1] docker gccgo support using it, and the "go build" invocation failed to produce a binary at the location specified by "-o", but did so with a zero exit code indicating success, which is much more alarming. Even adding "-v" to the build flags didn't produce any extra output to help narrow down the issue. > ... claims to be compatible with Go 1.4. In my own testing, this claim is dubious at best. The language support itself may be compatible (I didn't test it thoroughly enough to say for sure), but the tooling certainly isn't yet. (CCing #780355 because I'm even more firmly of the opinion of having packages explicitly declare support for gccgo now than I was before) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 [1]: https://github.com/docker/docker/pull/11298 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
