4 ms·

And they actually stuck with their go generate design? What an unfortunate mis-step. Let the makefile's continue. I've seriously thought about moving to gccgo

• bradfitz 12y ago
  You seem to be confusing compilers and build systems. You can use whatever build system you'd like and with whichever compiler.
  • Gracana 12y ago
    Is it possible to do away with the typical Go project directory structure? I thought all that was enforced by the tools, but it's possible that I didn't dig deep enough to uncover greater flexibility.
    • codemac 12y ago
      No it's not if you ever intend to type `go`. The go team has decided that the go language doesn't depend on any build system, but pushes a single build system one that requires source code compatibility and provides no benefit over many existing and easy to use build systems (makefiles, tup, etc).
  • codemac 12y ago
    I'm not sure what you define as a build system, but it's even in the description of the go build tool (https://golang.org/doc/articles/go_command.html https://golang.org/doc/articles/go_command.html): > An explicit goal for Go from the beginning was to be able to build Go code using only the information found in the source itself, not needing to write a makefile or one of the many modern replacements for makefiles. If Go needed a configuration file to explain how to build your program, then Go would have failed. And the hope is that go generate would be a hook into the dependency graph of go build. Much like the architecture switches, the naming conventions, etc, it seemed like it really could have solved my project's protobuf problem. But it's not, and for reasons that rob pike's doc and the mailing list did not make clear. It looks like a mis-step to me, and I don't think it's due to my misunderstanding of what `go build` and 6g/gccgo are
• noselasd 12y ago
  If you want or need to use makefiles to do whatever you want to do, use makefiles.