But having a way to (only) print the exact commands that will be run after all substitutions are done would be awesome.
Is this intended to be covered by -x and -n flags?
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
-rob
This is beautiful! Simplistic and powerful. I love the idea for generating custom sort types as well as the idea for embedding binary data.I could imagine another use-case for this as well: SWIG.
- SWIG would not have to be installed by anyone downloading a package.
- SWIG API's could be viewed in godoc, etc.
Of course, this would mean SWIG would have to generate code which can be compiled on every platform, but AFAIK it is already pretty close to that.
The -run flag takes a regular expression, analogous to that of the go test subcommand, that restricts generation to those directives whose command (see below) matches the regular expression.
//go:generate protoc foo.proto//go:generate protoc bar.proto//go:generate protoc baz.proto
-rob
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
-rob
what's the gain for the
effort of rewriting the Makefile into the annotations? I cannot find
the answer in the design document.
Can we standardize around the existing convention instead, or at least
support go:build and obsolete +build so we can eventually converge?
Agreed. And the user can always create whatever groupings they want by putting generate directives that should run together in the same go source file.
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
-rob
The generators are computer programs. They are capable of anything
computer programs can do.
The point of this proposal is to encourage experimentation. Experiment!
I have been experimenting with a code generator that would work well with this idea for about a year.
One of the (minor, ignorable) problems I found was the output began to be very large (1.3MB .s file for instance).Everytime I made a change to the generator then checked the code into a git repo the diff's were huge.Have you guys thought about doing something similar to this that would run during go test/build/run?You could create temp files then, similar to what cgo does.
One minor question, I will love to understand: Why the definition is done in a separeta file?
For me feels more natural (for go) to define how to build a file inside the target file.
For example:
main.go
request.pb
response.pb
messages.go
Inside messages.go have the proposed header, but the output of the command is pipe just after the header. For example, inside messages.go:
package main
// go:generate protob request.pb
// go:generate protob response.pb
Runnin go generate, will run the commands and concatenate the output in the same file, in the same order. The insertion point will be just after the last line of the first comment block (but probably there is a better way).
The benefits I see are:
* main.go remain clean, and I don't end with go generate directives around the codebase, making it simple. If I remove messages.go I don't have the mental effort of remembering in which file I put the directive.
* messages.go is the one defining how to build it self. No one else should.
* A collection of 50 pb files, will only generate one file, without doing any functionality shell concatenation.
* Enforce the use case of go:generate by only accepting the STDOUT of the command.
* I can freely define the package name and the documentation.
* No one will be tempted to gitignore that files and enforce clients to generate themselves (Don't like the idea of opening the door to need something but the go toolchain).
* The go file is the only one knowing how to generate it self. No one else should care. If I remove the file, I don't need to look and remove some macro in other file that is not related.
I also see several problems here, and seems ugly for me the modification of a file instead of a full replace. (And maybe is the reason why this was discard).
I will love to continue seeing go without directives/macros or anything that is not directly related with the file I am reading just because there is no a better place. Or having a generator.go with just directives (hello makefile).
On any case... I feel the need of these functionality
Thanks.
For me feels more natural (for go) to define how to build a file inside the target file.
* Enforce the use case of go:generate by only accepting the STDOUT of the command.
New go tool subcommand proposed for Go 1.4. Please see the design document and comment in this thread. http://golang.org/s/go1.4-generate
//go:generate /bin/rm -rf $HOMENoticing the problem after the fact won't be much of a consolation.
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
-rob
Perhaps “go gen -b” or “go build -g” would alleviate this problem.
The latter could be extended to “go get -g” which would (recursively?) get, generate, and build the packages you request. (Examples assume optimistically that s/generate/gen/g gains traction.)
Second, my next inclination will be to write something like this://go:gen -command useful-tool github.com/path/to/useful-toolBecause by ensuring that as many of my tools as possible are go gettable, I make it easy for clients (who I hope to enlist as contributors, right?) to have whatever tools they need to modify the library or tool.
On Wednesday, July 2, 2014 6:57:09 PM UTC-6, alfi...@gmail.com wrote:Perhaps “go gen -b” or “go build -g” would alleviate this problem.I thought about sub-proposing a -b (for build) flag to generate, but that's what shell scripts are for.
The latter could be extended to “go get -g” which would (recursively?) get, generate, and build the packages you request. (Examples assume optimistically that s/generate/gen/g gains traction.)That'd pretty much just apply to non-authors, and as specified, generate is specifically intended only for package authors.
Second, my next inclination will be to write something like this://go:gen -command useful-tool github.com/path/to/useful-toolBecause by ensuring that as many of my tools as possible are go gettable, I make it easy for clients (who I hope to enlist as contributors, right?) to have whatever tools they need to modify the library or tool.This is one case in which I'd prefer the author just ran generate on their own and committed the result; I don't want my $GOPATH/bin to be polluted with dozens of tools from everyone's personal build system. What you're describing (written in Go, for Go) specifically sounds like the basis for a Go-based preprocessor system, which would be a separate, competing proposal.
`go get` just builds and installs -- it doesn't run anything, so you can use get and _then_ inspect the code, you can still remain perfectly safe. Allowing get to implicitly call generate would mean that the act of fetching code is harmful, hence it's a very bad idea.
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
-rob
On Thursday, July 3, 2014 11:15:25 AM UTC-5, Kevin Gillette wrote:Except that shell scripts are generally non-portable. Most code generation, if done with go tools, would be trivially portable, so long as the code to invoke it were portable.
I'm not 100% sold on the idea that non-authors should be the norm. If my library is open source, it usually is so with the hope that users will contribute their efforts back and the community will benefit. Specifically... users /are/ authors, if all is working as one might hope.
It seems that you agree that there is a clear need for generating Go
code in some cases. If we accept that that need exists, what is the
downside to supporting it in the go tool? That is a serious question,
not a rhetorical one.
You've cited one downside, which is that it will encourage people to
run a bunch of external processing on their codebase. I don't see
that as a significant downside. I don't think the existence of "go
generate" is going to lead people to use code generation when they
wouldn't already do so.
Are there other downsides?
i don't really like the idea to get a package and not be able to (easily) recompile it myself the same way the package creator did.
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
See the output of "go help generate". I thought "whole-line comment"
was clear enough.
Maybe that means I wish the output of "go help foo" was available at http://golang.org/cmd/go/foo, or something like that.
See the output of "go help generate". I thought "whole-line comment"
was clear enough.
New go tool subcommand proposed for Go 1.4. Please see the design
document and comment in this thread.
http://golang.org/s/go1.4-generate
-rob