This changes the way we handle package imports for protobuf generated files. In the generated files, we need to declare a go import with the package import, i.e. github.com/edgexr/edge-cloud-platform/api/distributed_matching_engine. For locally generated files, this was being derived from the current working directory path. This required that the repo was checked out to $HOME/go/src/github.com/edgexr/edge-cloud-platform. This requirement cannot be guaranteed for 1) CICD, although in general we do not rebuild the generated files during CICD, and 2) go workspaces.
This change allows the repo to be checked out to any path and still end up with the correct imports. There are several cases to support. One is where we need to translate protobuf imports to golang imports: protobuf import api/distributed_match_engine/loc.proto -> golang import github.com/edgexr/edge-cloud-platform/api/distributed_match_engine. This is handled using Mfile=pkg annotations in the protoc command. Another is where we're generating separate package files (i.e. alert.notify.go) that need to refer to the original generated package (i.e. alert.pb.go). This is handled using a srcimport tag also on the protoc command.
The primary changes here are in the Makefiles and in support.go.
We specifically avoid the go_package option because we do not want to pollute the protobuf definition with a language-specific tag that affects (and restricts) the generated code. Additionally, the go_package option is not the correct solution for the DME protobufs which live is the separate edge-proto repo and are shared between this repo and the SDK repos.
This changes the way we handle package imports for protobuf generated files. In the generated files, we need to declare a go import with the package import, i.e.
github.com/edgexr/edge-cloud-platform/api/distributed_matching_engine. For locally generated files, this was being derived from the current working directory path. This required that the repo was checked out to$HOME/go/src/github.com/edgexr/edge-cloud-platform. This requirement cannot be guaranteed for 1) CICD, although in general we do not rebuild the generated files during CICD, and 2) go workspaces.This change allows the repo to be checked out to any path and still end up with the correct imports. There are several cases to support. One is where we need to translate protobuf imports to golang imports: protobuf import
api/distributed_match_engine/loc.proto-> golang importgithub.com/edgexr/edge-cloud-platform/api/distributed_match_engine. This is handled using Mfile=pkg annotations in the protoc command. Another is where we're generating separate package files (i.e. alert.notify.go) that need to refer to the original generated package (i.e. alert.pb.go). This is handled using asrcimporttag also on the protoc command.The primary changes here are in the Makefiles and in support.go.
We specifically avoid the
go_packageoption because we do not want to pollute the protobuf definition with a language-specific tag that affects (and restricts) the generated code. Additionally, thego_packageoption is not the correct solution for the DME protobufs which live is the separateedge-protorepo and are shared between this repo and the SDK repos.