Re-build third packages after of each release

[Archos]

When you build a new release, the third party packages (in $GOPATH)
should be re-built automatically, shouldn't?

So it's far easy to detect broken packes due to new changes in that
last release.

[Jan Mercl]

    $ go install -a ... # works well for me

or on a multicore machine I'd suggest:

    $ go install -a -p $(cat /proc/cpuinfo | grep processor | wc -l) ...

[minux]

I think this is not needed. The Go tool will use all available cpu cores by default.

[Jan Mercl]

On Wednesday, February 15, 2012 1:49:13 PM UTC+1, minux wrote:

On Wed, Feb 15, 2012 at 7:00 PM, Jan Mercl <jan.m...@nic.cz> wrote:

or on a multicore machine I'd suggest:

    $ go install -a -p $(cat /proc/cpuinfo | grep processor | wc -l) ...

I think this is not needed. The Go tool will use all available cpu cores by default.

My fault, you're right.

[Archos]

On Feb 15, 11:00 am, Jan Mercl <jan.me...@nic.cz> wrote:
> On Wednesday, February 15, 2012 10:50:50 AM UTC+1, Archos wrote:
>
> > When you build a new release, the third party packages (in $GOPATH)
> > should be re-built automatically, shouldn't?
>
> > So it's far easy to detect broken packes due to new changes in that
> > last release.
>
>     $ go install -a ... # works well for me

But it compiles AGAIN the packages in Go core.

[Kyle Lemons]

It's not as important as it used to be to recompile third-party packages.  Whenever you build a package that depends on them, they'll be built.

[minux]

Yes, this is a known problem (not a bug, I think). Maybe the go tool should take the

compiler version into account when determine whether some packages need to be

recompiled (This is indeed very useful, because the linker will likely to reject pkgs

compiled by another version (or branch) of compiler).