protobuf-go/cmd/protoc-gen-go/main.go

53 lines
1.5 KiB
Go
Raw Normal View History

// Copyright 2018 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// The protoc-gen-go binary is a protoc plugin to generate Go code for
// both proto2 and proto3 versions of the protocol buffer language.
//
// For more information about the usage of this plugin, see:
// https://developers.google.com/protocol-buffers/docs/reference/go-generated
package main
import (
"errors"
"flag"
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
"fmt"
"os"
"path/filepath"
gengo "google.golang.org/protobuf/cmd/protoc-gen-go/internal_gengo"
"google.golang.org/protobuf/compiler/protogen"
"google.golang.org/protobuf/internal/version"
)
func main() {
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
if len(os.Args) == 2 && os.Args[1] == "--version" {
fmt.Fprintf(os.Stderr, "%v %v\n", filepath.Base(os.Args[0]), version.String())
runtime/protoimpl, cmd/protoc-gen-go: support release versioning In order for protoc-gen-go to output the current version, it needs to know what version it is currently running as. However, we cannot rely on the git tags since the tags are not made until *after* the commit has been submitted. Instead, we manually encode the version into the code and make sure that git tags match up with the version in the code. The version.go file in runtime/protoimpl contains instructions for how to make a release. Essentially: * Every non-release commit has a version string with "devel" in it. * Every release commit must not have "devel" in it and must be unique. * The "release process" involves submitting two CLs. The first CL creates a version string without "devel", which is the commit that a git tag will actually reference. The second CL follows immediately and re-introduces "devel" into the version string. The following example shows a possible sequence of VersionStrings for git commits in time-ascending order: v1.19.0-devel (this CL) v1.19.0-devel v1.19.0-devel v1.19.0-devel v1.20.0-rc.1 <- tagged v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.1.devel v1.20.0-rc.2 <- tagged v1.20.0-rc.2.devel v1.20.0 <- tagged (future public release) v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.0-devel v1.20.1 <- tagged v1.20.1-devel v1.20.1-devel v1.21.0 <- tagged v1.21.0-devel Note that we start today with v1.19.0-devel, which means that our initial release will be v1.20.0. This number was intentionally chosen since 1) the number 20 has some correlation to the fact that we keep calling the new implementation the "v2" implementation, and 2) the set of tagged versions for github.com/golang/protobuf and google.golang.org/protobuf are unlikely to ever overlap. This way, the version of protoc-gen-go is never ambiguous which module it was built from. Now that we have version information, we add support for generating .pb.go files with the version information recorded. However, we do not emit these for .pb.go files in our own repository since they are always guaranteed to be at the right version (enforced by integration_test.go). Updates golang/protobuf#524 Change-Id: I25495a45042c2aa39a39cb7e7738ae8e831a9d26 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/186117 Reviewed-by: Damien Neil <dneil@google.com>
2019-07-10 07:15:35 +00:00
os.Exit(1)
}
var (
flags flag.FlagSet
plugins = flags.String("plugins", "", "deprecated option")
importPrefix = flags.String("import_prefix", "", "deprecated option")
)
protogen.Options{
ParamFunc: flags.Set,
}.Run(func(gen *protogen.Plugin) error {
if *plugins != "" {
return errors.New("protoc-gen-go: plugins are not supported; use 'protoc --go-grpc_out=...' to generate gRPC")
}
if *importPrefix != "" {
return errors.New("protoc-gen-go: import_prefix is not supported")
}
for _, f := range gen.Files {
internal/cmd/generate-protos: initial commit Create a single binary for handling generation of protos. This replaces previous logic spread throughout the repo in: * regenerate.bash * cmd/protoc-gen-go/golden_test.go * cmd/protoc-gen-go-grpc/golden_test.go * (indirectly) internal/protogen/goldentest One of the problems with the former approaches is that they relied on a version of protoc that was specific to a developer's workstation. This meant that the result of generation was not hermetic. To address this, we rely on the hard-coded version of protobuf specified in the test.bash script. A summary of changes in this CL are: * The internal_gengo.GenerateFile and internal_gengogrpc.GenerateFile functions are unified to have consistent signatures. It seems that the former accepted a *protogen.GeneratedFile to support v1 where gRPC code was generated into the same file as the base .pb.go file. However, the same functionality can be achieved by having the function return the generated file object. * The test.bash script patches the protobuf toolchain to have properly specified go_package options in each proto source file. * The test.bash script accepts a "-regenerate" argument. * Add generation for the well-known types. Contrary to how these were laid out in the v1 repo, all the well-known types are placed in the same Go package. * Add generation for the conformance proto. * Remove regenerate.bash * Remove internal/protogen * Remove cmd/protoc-gen-go/golden_test.go * Remove cmd/protoc-gen-go-grpc/golden_test.go * Add cmd/protoc-gen-go/annotation_test.go Change-Id: I4a1a97ae6f66e2fabcf4e4d292c95ab2a2db0248 Reviewed-on: https://go-review.googlesource.com/c/164477 Reviewed-by: Damien Neil <dneil@google.com>
2019-02-28 05:46:29 +00:00
if f.Generate {
gengo.GenerateFile(gen, f)
}
}
gen.SupportedFeatures = gengo.SupportedFeatures
return nil
})
}