Re: Re: "go build" performance question / feature request

"go get" also works on local packages, as a shortcut for "satisfy all my import dependencies and then go
install". 

On May 3, 2012, at 7:50 AM, "Phil S." <philipp.schumann@...> wrote:

> Oh ok, awesome. Should've thought of trying that! Thought go install
> is just for remote packages but then, of course that's what go get is
> for. Cheers!
> 
> 
> 
> On May 3, 12:38 pm, Kyle Lemons <kev...@...> wrote:
>> On Wed, May 2, 2012 at 7:39 PM, Phil S. <philipp.schum...@...> wrote:
>>> Hi gophers,
>> 
>>> now "go build" is a really neat tool but it seems like it recompiles
>>> all source files everytime,
>> 
>> This is somewhat overstating the case; for a single package, yes, it
>> compiles all source files whenever it recompiles that package.  That's not
>> a problem, because the go compilers are blisteringly fast.  It does not
>> recompile imported packages that are up-to-date, however, *except when you
>> are using local imports*. (one of the many reasons not to use them).  If
>> you notice that it's compiling a dependent package each time, you need to
>> "go install" them, as by default "go build" won't try to clobber existing
>> installed libraries.
>> 
>>> making a clean temp directory that it
>>> later deletes again, even if only one (and quite often fairly small)
>>> source file was changed.
>> 
>> The temp directory is for build artifacts.  The number of files changed is
>> irrelevant to what gets put there.  The "go build" command "shadows" any
>> stale package archives by compiling them into this temp directory in favor
>> of blowing away whatever may or may not be installed in $GOPATH/pkg without
>> permission.
>> 
>>> Now if I went the manual way with 6g and 6l, I would only have to 6g
>>> the changed file and then 6l the output of that, and 6l whatever
>>> depends on it up to the main package.
>> 
>> That is indeed what the go tool does, when you tell it to do so (via "go
>> install").
>> 
>>> Which should be a great deal faster than brute-force recompiling and
>>> relinking a bigger package's entire src tree.
>> 
>> Again, that's not what it does.
>> 
>>> I presume go build already does parse imports to build a dependency
>>> tree in order to issue gc and ld calls in the proper order.
>> 
>> Yep, it does.  "go list -f {{.Deps}} ." to see :)