Joel Sing said:
> I obviously did not get to look carefully at r1.2 of go.port.mk - there are a 
> number of issues that should be resolved:
> 
> - Running 'go install -x' and piping the results through sed and sh -v is 
> crazy. Firstly, 'go install -x' will *run* those commands, then they're being 
> run a second time around via sh. Not to mention that there are cases where 
> replacing GOROOT is wrong. If Go is writing outside of GOPATH then it is 
> either being called/used incorrectly, or there is a bug that should be fixed.
> 
> - Using -work is going to cause mess since it prints the work directory and 
> leaves the work directory behind. I cannot see anything that is cleaning this 
> up, so we're left with /tmp/go-build*.
> 
> - Using 'go build -a' should be unnecessary - furthermore, the semantics of 
> -a 
> have changed between go1.4 and go1.5. In go1.4 the standard library was 
> excluded from the -a flag whereas for go1.5 it does mean all dependencies 
> including the standard library (this was the same for go1.3). However, there 
> is a blanket 'do not rebuild standard library packages' in place when the -a 
> flag is not specified.

The module was built for go 1.4, and most of it needs rewrite for 1.5.
There are also other issues with it.  I'd rather decouple update of
golang port from update of go ports and this module.

> This brings me to the next issue/topic - installing additional packages under 
> /usr/local/go is probably a bad idea. The biggest issue is that Go treats 
> packages under that path as being 'standard library' and as such, they do not 
> get rebuilt unless the -a flag is used. The Go development model is that you 
> fetch additional packages into your workspace - obviously this does not work 
> that well for prepackaged/compiled code. There are likely two options - we 
> could install packages in a separate location (e.g. /usr/local/go-pkg) and 
> then when code is built it is added to GOPATH.

I had some issues with this approach with go 1.4.  If it works with 1.5,
I am all for it, albeit I'd rather use location under /usr/local/go
root, eg. /usr/local/go/3rdparty.

> Alternatively, the code is fetched and built when the binary is built
> (for example, when building net/websocketd, net/go-websocket is pulled
> in and compiled at the same time.

This happens during build stage, which should never happen in ports.

-- 
Dmitrij D. Czarkoff

Reply via email to