// Protocol Buffers - Google's data interchange format | |
// Copyright 2008 Google Inc. All rights reserved. | |
// http://code.google.com/p/protobuf/ | |
// | |
// Redistribution and use in source and binary forms, with or without | |
// modification, are permitted provided that the following conditions are | |
// met: | |
// | |
// * Redistributions of source code must retain the above copyright | |
// notice, this list of conditions and the following disclaimer. | |
// * Redistributions in binary form must reproduce the above | |
// copyright notice, this list of conditions and the following disclaimer | |
// in the documentation and/or other materials provided with the | |
// distribution. | |
// * Neither the name of Google Inc. nor the names of its | |
// contributors may be used to endorse or promote products derived from | |
// this software without specific prior written permission. | |
// | |
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS | |
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT | |
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR | |
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT | |
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, | |
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT | |
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | |
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY | |
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | |
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE | |
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | |
// Author: kenton@google.com (Kenton Varda) | |
// | |
// WARNING: The plugin interface is currently EXPERIMENTAL and is subject to | |
// change. | |
// | |
// protoc (aka the Protocol Compiler) can be extended via plugins. A plugin is | |
// just a program that reads a CodeGeneratorRequest from stdin and writes a | |
// CodeGeneratorResponse to stdout. | |
// | |
// Plugins written using C++ can use google/protobuf/compiler/plugin.h instead | |
// of dealing with the raw protocol defined here. | |
// | |
// A plugin executable needs only to be placed somewhere in the path. The | |
// plugin should be named "protoc-gen-$NAME", and will then be used when the | |
// flag "--${NAME}_out" is passed to protoc. | |
package google.protobuf.compiler; | |
option java_package = "com.google.protobuf.compiler"; | |
option java_outer_classname = "PluginProtos"; | |
import "google/protobuf/descriptor.proto"; | |
// An encoded CodeGeneratorRequest is written to the plugin's stdin. | |
message CodeGeneratorRequest { | |
// The .proto files that were explicitly listed on the command-line. The | |
// code generator should generate code only for these files. Each file's | |
// descriptor will be included in proto_file, below. | |
repeated string file_to_generate = 1; | |
// The generator parameter passed on the command-line. | |
optional string parameter = 2; | |
// FileDescriptorProtos for all files in files_to_generate and everything | |
// they import. The files will appear in topological order, so each file | |
// appears before any file that imports it. | |
// | |
// protoc guarantees that all proto_files will be written after | |
// the fields above, even though this is not technically guaranteed by the | |
// protobuf wire format. This theoretically could allow a plugin to stream | |
// in the FileDescriptorProtos and handle them one by one rather than read | |
// the entire set into memory at once. However, as of this writing, this | |
// is not similarly optimized on protoc's end -- it will store all fields in | |
// memory at once before sending them to the plugin. | |
repeated FileDescriptorProto proto_file = 15; | |
} | |
// The plugin writes an encoded CodeGeneratorResponse to stdout. | |
message CodeGeneratorResponse { | |
// Error message. If non-empty, code generation failed. The plugin process | |
// should exit with status code zero even if it reports an error in this way. | |
// | |
// This should be used to indicate errors in .proto files which prevent the | |
// code generator from generating correct code. Errors which indicate a | |
// problem in protoc itself -- such as the input CodeGeneratorRequest being | |
// unparseable -- should be reported by writing a message to stderr and | |
// exiting with a non-zero status code. | |
optional string error = 1; | |
// Represents a single generated file. | |
message File { | |
// The file name, relative to the output directory. The name must not | |
// contain "." or ".." components and must be relative, not be absolute (so, | |
// the file cannot lie outside the output directory). "/" must be used as | |
// the path separator, not "\". | |
// | |
// If the name is omitted, the content will be appended to the previous | |
// file. This allows the generator to break large files into small chunks, | |
// and allows the generated text to be streamed back to protoc so that large | |
// files need not reside completely in memory at one time. Note that as of | |
// this writing protoc does not optimize for this -- it will read the entire | |
// CodeGeneratorResponse before writing files to disk. | |
optional string name = 1; | |
// If non-empty, indicates that the named file should already exist, and the | |
// content here is to be inserted into that file at a defined insertion | |
// point. This feature allows a code generator to extend the output | |
// produced by another code generator. The original generator may provide | |
// insertion points by placing special annotations in the file that look | |
// like: | |
// @@protoc_insertion_point(NAME) | |
// The annotation can have arbitrary text before and after it on the line, | |
// which allows it to be placed in a comment. NAME should be replaced with | |
// an identifier naming the point -- this is what other generators will use | |
// as the insertion_point. Code inserted at this point will be placed | |
// immediately above the line containing the insertion point (thus multiple | |
// insertions to the same point will come out in the order they were added). | |
// The double-@ is intended to make it unlikely that the generated code | |
// could contain things that look like insertion points by accident. | |
// | |
// For example, the C++ code generator places the following line in the | |
// .pb.h files that it generates: | |
// // @@protoc_insertion_point(namespace_scope) | |
// This line appears within the scope of the file's package namespace, but | |
// outside of any particular class. Another plugin can then specify the | |
// insertion_point "namespace_scope" to generate additional classes or | |
// other declarations that should be placed in this scope. | |
// | |
// Note that if the line containing the insertion point begins with | |
// whitespace, the same whitespace will be added to every line of the | |
// inserted text. This is useful for languages like Python, where | |
// indentation matters. In these languages, the insertion point comment | |
// should be indented the same amount as any inserted code will need to be | |
// in order to work correctly in that context. | |
// | |
// The code generator that generates the initial file and the one which | |
// inserts into it must both run as part of a single invocation of protoc. | |
// Code generators are executed in the order in which they appear on the | |
// command line. | |
// | |
// If |insertion_point| is present, |name| must also be present. | |
optional string insertion_point = 2; | |
// The file contents. | |
optional string content = 15; | |
} | |
repeated File file = 15; | |
} |