Lots of things that are good for communities are restricting for individuals. Even more interesting, some of them lose significant value when anything less than a super-majority fall in line with them (This for example is why I think the Go community sometimes is very "passionate" about getting people on the right path, they are threatening the herd immunity of sane code and layout... one person goes off, others see their example and copy it... chaos!). I think the Go team was wise enough to see that the value of having sane baked in standards from day one FAR outweighed the complaints they knew would follow.

I think many people put too little value on communal norms, they have substantial value and are worth the adaption time. When in Windows C++ -- follow the conventions, when in Linux C -- again, follow the conventions -- and when in Go -- do that same. Fighting the dominant style for established platforms and languages is a mostly pointless, exhausting and sometimes debilitating task generally only done by those too inexperienced to realize how ridiculous it is. Team leads more experienced tend to just choose whatever is the dominate style / layout (preferably per-written up) for that platform/language realizing the benefits for getting ease of reading, consistency, hiring, firing, flexible labor (consultants) and most importantly not having absolutely worthless debates about style and layout.

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?

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.