On 16/05/14 22:55, John Meinel wrote:
> FWIW, I wrote this little bash function and put it in my ~/.bashrc
> function gotest {
> p="-gocheck.v"
> f=""
> if [ -n "$1" ]; then
> if [ "$1" = "-r" ]; then
> p="./..."
> else
> f="-gocheck.f=$f"
> fi
> fi
>
FWIW, I wrote this little bash function and put it in my ~/.bashrc
function gotest {
p="-gocheck.v"
f=""
if [ -n "$1" ]; then
if [ "$1" = "-r" ]; then
p="./..."
else
f="-gocheck.f=$f"
fi
fi
go test $p $f && go test -compiler=gccgo $p $f
}
That lets m
Thanks Tim,
I think we're in the position that even if you don't use gccgo for
your own development (understandable, it is slower), now that we have
platforms we support in Trusty that must use gccgo, armv8 and ppc64el,
for any new development, the code has to pass under both compilers.
This is a
I realise I left this bit hanging:
On 16/05/14 14:41, Tim Penhey wrote:
> A key issue that Dave and I have been poking with a stick is the test
> suite for juju/errgo, as it had some failures with gccgo (all passed
> with gc).
In the end it had to do with the runtime.Caller method for stack
analy
Hi folks,
I'm sure most of you are aware that we now use gccgo to compile juju for
the ppc64el and arm64 architectures.
We have a great [0] test suite with juju, and also for most of the
packages that we depend on. However we can't gate every commit on
testing with both compilers on all the arch
