The centralized golang tree structure I described and use is not a case of
going against golang defaults. It's a case of amending the default paths
for the purpose of bringing it all in one place, all golang related, that
is. On every machine I develop with golang, my first *blind *thought is to
Sorry, I've lost it at "golang dev space", but I guess there could be
an explicit definition to that new phrase. (Though if that definition
is not used anywhere else, I can't see any value in that either.)
The directories exposed by the environment variables are not there to
be explicitly managed w
Yes, you can safely assume we can agree to disagree on the value of my
version for containment, no problem here :)
My problem starts with the containment of the golang dev space for the
user. Going from here, what dir names should I use? So I thought that using
a dir tree based on envvars names
On 12/9/20, Dumitru Ungureanu wrote:
> I decided to place them all in one place for containment.
Thanks! (Though I believe we can agree to disagree on the value of
this version of containment.)
> I used the names from envvars to get a simple answer to a simple question:
> *where is GOROOT?*, *in
I decided to place them all in one place for containment.
I used the names from envvars to get a simple answer to a simple question:
*where
is GOROOT?*, *in go/root*.
GOMODCACHE picks up GOPATH.
GOTOOLDIR picks up GOROOT.
GOTMPDIR defaults to system's tmp dir, I'm fine with that.
On Wednesday, D
To clarify the go compiler toolchain is a trivial tree. Compared to
most other mainstream languages and compilers, it's not scattered to
different subtrees. I believe quite some effort went into that to stay
that way.
When using the go compiler toolchain some directories are used for
caching compil
Yes, there is no requirement to manage the envvars. I personally believe
there is a requirement to know about them, though.
I read the installation doc, I think there's a hang up on your part on this
one.
The default go tree is scattered different places, beside the obvious
trivial tree you're m
There is no requirement to manage these variables or to know about them,
even if you don't use the installer.
I never use the installer and I've never needed to check on those
environment variables.
(The installation documentation is short and complete, maybe you should
check it out again.)
The
I don't use an installer. I set GOROOT/bin manually. And the rest follows.
Easy to remember, nothing to forget.
On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
> On 12/8/20, Dumitru Ungureanu wrote:
> > Paths in symmetry with the environmental
> > variables: GOROOT is g
On 12/8/20, Dumitru Ungureanu wrote:
> Paths in symmetry with the environmental
> variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
> go/cache, GOENV is go/env.
> Bonus points: modules in go/modules.
Why do you need to manage them explicitly? When do you need to look at
Paths in symmetry with the environmental
variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
go/cache, GOENV is go/env.
Bonus points: modules in go/modules.
On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
> On 12/7/20, Dumitru Ungureanu wrote:
On 12/7/20, Dumitru Ungureanu wrote:
...
> I'm currently using this directory tree for golang.
...
What do you mean when you write "golang"?
Why is https://golang.org/doc/install not good enough for the go compiler?
--
You received this message because you are subscribed to the Google Groups
"
Hi.
I'm currently using this directory tree for golang. Is there something I'm
not taking into consideration, maybe? Thanks.
├─ go
│ ├─ bin (GOBIN, where install command deploys binaries)
│ ├─ cache (GOCACHE, where cached builds await reuse)
│ ├─ modules
│ ├─ path (GOPATH, first workspace, w
13 matches
Mail list logo
