build world question

136 views
Skip to first unread message

Hotei

unread,
Mar 17, 2021, 1:57:55 PMMar 17
to golang-nuts
Heeding the prodding of the go gurus on this list I just converted a bunch of old code to modules and was wondering what the "module" equivalent to "go build ./..." is.  I used to be able to use that command at the top of my code tree and it would attempt to build everything in the subdirs.  Doesn't seem to work now even though each subdir compiles fine individually.  Haven't been reading golang-nuts every day so sorry if I missed a previous topic that solves this.

Thanks

Brian Candler

unread,
Mar 17, 2021, 3:29:37 PMMar 17
to golang-nuts
What error do you see?

Are your subdirectories independent modules in their own right (i.e. they have their own "go.mod"), or just separate packages within the same module (go.mod only exists at the top level)?  Normally the latter is what you want.

Hotei

unread,
Mar 18, 2021, 9:57:46 AMMar 18
to golang-nuts
Brian, 
Looks like a case of "pilot error".  After tinkering a bit more it started to work.  Each directory has its own go.mod file.  Took a little while to figure out what the module wanted to see for versioning but that's seems to be sorted now.  Still have  a large number of projects to convert but at least the process seems to be working ok.  Thanks for the assistance.  
David

Brian Candler

unread,
Mar 18, 2021, 11:51:19 AMMar 18
to golang-nuts
OK.  I'll just point out that if the repo contains a set of related packages, then normally you'd only put a go.mod at the top level.

For an example of this in action, see the "testify" group of packages:

The subdirectories are separate packages.  For example I can do

import (
)
...
    assert.NotEqual(t, 1, 2)
    require.True(t, true)

However, you'll see there's no go.mod in the package directories.  They are anchored to the go.mod at the root.

Jan Mercl

unread,
Mar 18, 2021, 12:02:12 PMMar 18
to Brian Candler, golang-nuts
On Thu, Mar 18, 2021 at 4:51 PM Brian Candler <b.ca...@pobox.com> wrote:

> OK. I'll just point out that if the repo contains a set of related packages, then normally you'd only put a go.mod at the top level.

I think the OP never mentioned a repository but "world". I infer that
means all the repositories the OP is dealing with on some machine,
probably everything under $GOPATH/src.

Hotei

unread,
Mar 18, 2021, 10:46:23 PMMar 18
to golang-nuts
Jan,
To clarify a bit, "world" used to be everything under $GOPATH/src.   Since gophers can expect at some point to see $GOPATH go away the directory I now refer to as "world" is just a local/private version of my github.com/hotei repository with about 250 or so subdirs that represent individual projects.  I'm about halfway through the conversion process and it's pretty much down to a lot of typing now.  Go has gotten a bit more complex lately with vendoring and modules but in my opinion it's still the best choice for development. One particular strength I can vouch for is that I can look at go code I wrote 10 years ago and 99% of the time I understand what I was doing at the time.  Can't recall any other language I've used for which I can say the same.
David
Reply all
Reply to author
Forward
0 new messages