Building a Package With Multiple Subdirectories?

[jlfo...@berkeley.edu]

Back in June I asked why Go requires all the files in a package to be in the same

directory. I learned that this is an implementation-specific decision. I was also referred to

https://stackoverflow.com/questions/45899203/can-i-develop-a-go-package-in-multiple-source-directories

which discusses this. Someone named "Volker" in this posting said

"Yes, this is doable without any problems, just invoke the Go compiler by hand, that is not

via the go tool."

I'm wondering how to actually do this. Suppose I have a directory, which contains several

subdirectories. There are .go files in all these directories that I'd like to use to make a

single package. How could I invoke to Go compiler by hand to make this happen?

(I've tried adding the "-x" flag to "go build" but I don't see which arguments I'd need to

change to do what I'm trying to accomplish). Volker says "It's complicated".

Also, let's say I was able to figure this out. Would using such a package confuse any of

the other commands in the Go tool chain or the dlv debugger?

Cordially,

Jon Forrest

[Amnon]

Don't do it.
Don't fight the Go tools. Use them the way they are intended. They are your friends.
Put all your package files in a single directory. Or break them up into multiple packages.
That is the way everyone else write Go. If you follow the convention, your life will be simpler,
and your code will be easier for others to understand and maintain.

[jlfo...@berkeley.edu]

The reason I'm asking this question is because, as a learning exercise, I'm trying to

rewrite several large existing applications in Go. These have been around a while

and have a very sensible source subdirectory layout, sometimes with multiple levels of

subdirectories.

My initial approach was going to be to have each source subdirectory tree be a Go package.

That would allow me to concentrate on the Go code, which is less work than a total source

reorganization.

I had also thought about creating multiple packages, as you suggest. What worries me about

this approach is that it increases the chance of import cycles.

I'm still pondering this issue.

Cordially,

Jon Forrest

[Christian Stewart]

Doesn't it make more sense to fix the cyclic dependencies rather than hack the go compiler and make it do something it wasn't designed to do?

Best regards,

Christian

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5c19ed2f-caab-4fa4-b21d-37c3d9c9d0e9n%40googlegroups.com.

[jlfo...@berkeley.edu]

It might indeed make more sense to fix the cyclic dependencies. I'm not even sure

there will be any. I'm just trying to anticipate possible problems.

Thanks,

Jon