[abofh]

For what its worth, go the language doesn't force that structure. Go the tool does most of that. Most languages (in their pubescent state) don't have self-referential build tools, and so tools get added by third parties (make, scons, etc).

This is not a bad thing -- but it does mean that when a language chooses to ship "opinionated" tools as the default supporting toolset, users gain from the 'convention over code' as rails would call it - you run go build and the tool does the math -- but accomplishing source-tree validation across arbitrary maintainers trees is less trivial than "package-path == path" -- so if you name your code "com.foo.baz.bar", you'll be hurt by its opinions.

That said - if you want to learn the toolchain, 6c/6g/6l (and its 5/8 counterparts) will act like the simplest gcc tools - so long as the benefit you gain from manual definition outweighs the cost, you still win without "go build".

[Sir_Cmpwn]

I like the idea of writing Go independently from the Go tool. Could you offer some brief insight into how dependency resolution might work, and link to some projects that break the mold?

[burntsushi]

Dependency resolution is done by the `go` tool automatically. If your project isn't compatible with the conventions established by the `go` tool, then it cannot infer your project's dependencies automatically.

I'm not aware of any projects that break the mold. Almost everyone that writes Go perceives the benefits of the `go` tool to be greater than the cons.

In another comment, I suggested using symlinks. I do it. Is there a reason why that doesn't work for you?

[abofh]

it's been a while, but something approximating:

-- HN has eaten my asterisks, sed {asterisk} appropriately.

(locate your {5,6,8}{c,l,g} per your go install, or use 'go tool' if you want to go half-way in, I'll use go tool '6' (amd64) for reference).

go tool 6g {asterisk}.go

if you're linking to a final binary:

go tool 6l -o outname {asterisk}.6

Then run ./outname

I'm eliding over linking and includes, but if you run 'go tool 6l -help', you'll find all your expected 'include' and 'link' directory type parameters.

...

All of that aside, I've found it rare that I actively link go code to languages outside of C, and even then, only rarely do I need to share the C subset outside of the 'go' repo. So I'd step back for a second before you go down this road and ask _why_ it must conform. I assume you have a reason -- and if you have a reason and want go as well, exploring the nitty-gritty of 'go tool' is going to be a must. I found it easier to conform with go in a different repository - that may not be an option for you.

[Sir_Cmpwn]

One of the biggest "why" answers is software distribution. I distribute my code in source form and users expect to ./configure && make && make install. I feel like there's far too much manual intervention in "the Go way" that I'd be asking my non-Go-savvy users to embark upon.