Unclear how to use protobufs with go tool

[GoogleCodeExporter]

What steps will reproduce the problem?

The README outlines how to use a Makefile to generate the go source for a 
protocol buffer. However, it seems apparent from Go documentation that 
Makefiles are deprecated in lieu of the go command. There should, imho, at 
least be an explanation that the Makefile is necessary despite the 
recommendations in Go documentation, and possibly an assurance that it will 
continue to work.

If the go command is going to function as a full build system (and it seems 
aimed that way given the nice work to interact with cgo), and Makefiles are 
going to be completely deprecated, then something (not sure what, sorry!) needs 
to be done.

I understand that this issue falls awkwardly somewhere between the 
responsibilities of the core golang team and goprotobuf.

Original issue reported on code.google.com by ian.sche...@gmail.com on 25 Feb 2013 at 3:01

[GoogleCodeExporter]

Yes, this is a known problem. There's not a good answer right now.

The current best option is to generate the .pb.go files, and check them in to 
your source control in a suitable directory. The go tool will work fine with 
that, and there's zero extra tools that need to be installed to be able to use 
that package. Then you only have to deal with regenerating them when your 
.proto files change.

Original comment by dsymo...@golang.org on 25 Feb 2013 at 3:09

• Changed title: Unclear how to use protobufs with go tool
• Changed state: Accepted

[GoogleCodeExporter]

Makefiles are not deprecated in general, they are just not necessary if your 
program is pure Go. There are many Makefiles in the Go repo, for instance.

Protobufs are not Go. Without building support for the protobuf tool into the 
go command (which won't happen soon, if ever), make remains a good way to build 
Go programs that depend on protobufs.

I disagree with David on his definition of the best option, since it 
complicates development of the protobuf definition itself. But do what works 
best for you.

Original comment by r@golang.org on 25 Feb 2013 at 5:48

• Changed state: WorkingAsIntended