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 my write:
gotest
gotest -r
and
gotest justOneSuite
I'm sure something better could be done, but that makes things immediately
useful.
The compile time is noticeably slower at getting the tests running (so this
slows down iteration >2x), but until gccgo is ironed out it is probably
still worthwhile.
John
=:->
On Fri, May 16, 2014 at 6:53 AM, David Cheney <david.che...@canonical.com>wrote:
> 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 bit of a bummer, but at least if you are running trusty on
> your development environment, you have all the bits you need[1][2].
>
> Running tests, for a single package then becomes
>
> go test && go test -compiler=gccgo
>
> With respect to the whole Juju test suite, even after months of work
> there still remain a few tests which do not pass under trusty, these
> are tracked with bugs in lp, just look for the gccgo label if you find
> yourself at a loose end.
>
> Cheers
>
> Dave
>
> [1] Prior to trusty, you'd probably be using gccgo-4.8, which is not
> of acceptable quality for use with Juju.
> [2] If for some reason you don't want to upgrade to trusty, we may be
> able to ask Doko for a backport of gccgo-4.9, but really, just upgrade
> to trusty.
>
> On Fri, May 16, 2014 at 12:44 PM, Tim Penhey <tim.pen...@canonical.com>
> wrote:
> > 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
> > analysis, and the synthetic methods that gccgo was creating. The
> > solution was simply enough to convert the tests to use gocheck, that way
> > the synthetic methods that were being created are higher in the stack
> > that we ever look in the tests, and it is all good.
> >
> > Tim
> >
> >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
