Comment 1:

There is no general support for side inputs in that way at the moment. It may need to be
addressed long-term, but for right now the "go" tool is simply not the right tool for
that job.

Labels changed: added priority-later, removed priority-triage.

Comment 2:

Our plan for this is to have a toplevel Makefile where you can type
make prepare
to run goyacc, protoc and whatever other code generators you have so that the go tool
just sees .go files. This means you need to remember to make prepare when you change
these "original" inputs, but you'll usually know when you're doing this kind of thing so
you can do:
make prepare all
(all calls the go tool). Or if the prepare step is fast enough, you can always do it
before having the Makefile run go.

Comment 3:

This is likely to stay this way.  If you check in the generated file
then everyone using your package doesn't have to find the tools
you are using.

Status changed to LongTerm.

Comment 4:

Now that we have some experience with the go tool I can say #3 definitively.

Status changed to WorkingAsIntended.

Comment 5:

I have a trivial (as in, perhaps not feature complete) implementation in
https://golang.org/cl/48360043

Comment 6:

rsc's #3/#4 comments imply that we can't depend on yacc being part of the Go toolchain.
jaq, your CL assumes that. One of those would have to change or else we end up with
builds that only sometimes work.

Comment 7 by jaq@spacepants.org:

I didn't see that implication (on first reading), but sure, the change certainly does
rely on yacc existing if you have a .y source file.  It could be made more robust to a
missing binary just as go tool does for other tools it knows about, in cmd/go/tool.go:56
, were one to think that code generation should be something that go tool ought to
support.
Note that this change doesn't cause the *go* build to only sometimes work, though.
But (or, regardless) perhaps cmd/yacc should be moved to the go.tools repository instead.
To a newcomer (as I was when I filed this bug) it seemed that having the tool here
implied one should be able to rely on it during the build process.  If the go tool is
never going to support code generators, then it seems misleading to leave it in the
primary repo.

Comment 8 by jaq@spacepants.org:

That was a bit rambly; let me resummarise:
1) I think regardless of the decision to support code generation tools in the go tool,
cmd/yacc should move to the go.tools repository.
2) I think go tool should support code generation tools as part of the build process. 
That a tool could be missing is not a large burden on a build process, given that
cmd/go/tools.go:56 already handles known tools that are not yet installed with a
reasonable error message.

Comment 9:

The go tool cannot blindly invoke goyacc. For example, what if the project/package has
more than one .y file?

Comment 10 by jaq@spacepants.org:

That is a strange question, 0xj, and orthogonal to this issue.
(The suggested change handles more than one .y file in a project, and any theoretical
"blind" invocation of goyacc would merely be an implementation bug, though I am not sure
what you mean by "blind."  I am more interested in if the go team are amenable to having
code generators in general supported as a feature of go build.)

Comment 11:

@10: I don't know what you find strange on the question, but I'm sure it is not
orthogonal to the discussion.
_"The suggested change handles more than one .y file in a project"_
No it doesn't. The CL invokes the yacc blindly, ie. without knowing what -p flag value
was chosen by the programmer. That means that with more than one .y file in a
package/command, the CL would provide duplicate declarations and the package/command
will not compile.
Even worse, the problem can demonstrate itself even in the case of just one .y file, see
[0]. Here the prefix has to be set to "expr" by '-p expr'. Without that the example no
more compiles as eg. 'exprParse' at [1] would be undefined. The build tool currently has
no way how to figure out the chosen - if required - '-p' flag value, so automagically
invoking the yacc tool without that value - where required - is why I call 'invoking it
blindly': sometimes it will work, in some other cases it will not.
----
(09:47) jnml@r550 ~/go/src/cmd/yacc $ ll
celkem 80
-rw-r--r-- 1 jnml jnml  1592 lis 28 12:00 doc.go
-rw-r--r-- 1 jnml jnml  3287 lis 28 12:00 expr.y
-rw-r--r-- 1 jnml jnml   266 lis 28 12:00 Makefile
-rw-r--r-- 1 jnml jnml 67493 lis 28 12:00 yacc.go
(09:47) jnml@r550 ~/go/src/cmd/yacc $ go tool yacc -o expr.go expr.y
(09:48) jnml@r550 ~/go/src/cmd/yacc $ go run expr.go
# command-line-arguments
expr.y:110[/home/jnml/go/src/cmd/yacc/expr.go:58]: undefined: exprSymType
expr.y:136[/home/jnml/go/src/cmd/yacc/expr.go:84]: undefined: exprSymType
expr.y:203[/home/jnml/go/src/cmd/yacc/expr.go:151]: undefined: exprParse
(09:48) jnml@r550 ~/go/src/cmd/yacc $ 
----
  [0]: http://code.google.com/p/go/source/browse/src/cmd/yacc/expr.y#7
  [1]: http://code.google.com/p/go/source/browse/src/cmd/yacc/expr.y#203

Comment 12 by jaq@spacepants.org:

I'm sorry.  You make a good point.  I thought you were only referring to the default
output filename.
However, the CL description hints at my plan for addressing that issue: either something
that looks like the +build notation, that go tool would understand to pass flags to
yacc, or copying GNU bison for it's %option syntax and implementing that directly in
yacc.go.
I consider this orthogonal because it's a surmountable technical detail that doesn't
exist if the discussion ends up rejecting my suggestion.