Skip to content
This repository has been archived by the owner on Feb 8, 2022. It is now read-only.

create froto.exe #11

Closed
ctaggart opened this issue Jan 21, 2016 · 4 comments
Closed

create froto.exe #11

ctaggart opened this issue Jan 21, 2016 · 4 comments

Comments

@ctaggart
Copy link
Owner

The idea is to create a froto.exe that is similar to protoc.exe in that it reads in a .proto file and generates source code. There may be a few different source code generators, including:

  • Roslyn based C# generator for proto2 that generates code for protobuf-net.
  • F# code generator via FsAst that support proto3 and builds on top of the Google.Protobuf library. It will use F# Records and Options.
  • Roslyn based C# generator for proto3 that generates code for Google.Protobuf library, but differs from the protoc.exe generated code in a few ways.

Just for information, the protoc.exe in Google.Protobuf 3.0.0-beta2 has this help:

PS C:\fs\froto> .\packages\Google.Protobuf\tools\protoc.exe --version
libprotoc 3.0.0
PS C:\fs\froto> .\packages\Google.Protobuf\tools\protoc.exe --help
Usage: C:\fs\froto\packages\Google.Protobuf\tools\protoc.exe [OPTION] PROTO_FILES
Parse PROTO_FILES and generate output based on the options given:
  -IPATH, --proto_path=PATH   Specify the directory in which to search for
                              imports.  May be specified multiple times;
                              directories will be searched in order.  If not
                              given, the current working directory is used.
  --version                   Show version info and exit.
  -h, --help                  Show this text and exit.
  --encode=MESSAGE_TYPE       Read a text-format message of the given type
                              from standard input and write it in binary
                              to standard output.  The message type must
                              be defined in PROTO_FILES or their imports.
  --decode=MESSAGE_TYPE       Read a binary message of the given type from
                              standard input and write it in text format
                              to standard output.  The message type must
                              be defined in PROTO_FILES or their imports.
  --decode_raw                Read an arbitrary protocol message from
                              standard input and write the raw tag/value
                              pairs in text format to standard output.  No
                              PROTO_FILES should be given when using this
                              flag.
  -oFILE,                     Writes a FileDescriptorSet (a protocol buffer,
    --descriptor_set_out=FILE defined in descriptor.proto) containing all of
                              the input files to FILE.
  --include_imports           When using --descriptor_set_out, also include
                              all dependencies of the input files in the
                              set, so that the set is self-contained.
  --include_source_info       When using --descriptor_set_out, do not strip
                              SourceCodeInfo from the FileDescriptorProto.
                              This results in vastly larger descriptors that
                              include information about the original
                              location of each decl in the source file as
                              well as surrounding comments.
  --dependency_out=FILE       Write a dependency output file in the format
                              expected by make. This writes the transitive
                              set of input file paths to FILE
  --error_format=FORMAT       Set the format in which to print errors.
                              FORMAT may be 'gcc' (the default) or 'msvs'
                              (Microsoft Visual Studio format).
  --print_free_field_numbers  Print the free field numbers of the messages
                              defined in the given proto files. Groups share
                              the same field number space with the parent
                              message. Extension ranges are counted as
                              occupied fields numbers.

  --plugin=EXECUTABLE         Specifies a plugin executable to use.
                              Normally, protoc searches the PATH for
                              plugins, but you may specify additional
                              executables not in the path using this flag.
                              Additionally, EXECUTABLE may be of the form
                              NAME=PATH, in which case the given plugin name
                              is mapped to the given executable even if
                              the executable's own name differs.
  --cpp_out=OUT_DIR           Generate C++ header and source.
  --csharp_out=OUT_DIR        Generate C# source file.
  --java_out=OUT_DIR          Generate Java source file.
  --javanano_out=OUT_DIR      Generate Java Nano source file.
  --js_out=OUT_DIR            Generate JavaScript source.
  --objc_out=OUT_DIR          Generate Objective C header and source.
  --python_out=OUT_DIR        Generate Python source file.
  --ruby_out=OUT_DIR          Generate Ruby source file.
@jhugard
Copy link
Collaborator

jhugard commented Jan 22, 2016

What is the advantage of using FsAst for code generation over, say, just a bunch of printf statements? Seems like the latter would create far less code noise and would be considerably easier to maintain... Plus, you're already considering using Roslyn for run-time code generation (or for fueling a Type Provider).

I've seen one project which uses XSLT, but that suffers the same complexity problem: not very easy to read and maintain...

@jhugard
Copy link
Collaborator

jhugard commented Jan 22, 2016

I get why you'd like to have a back-end to generate Proto.net code (from what I've heard, their proto-first solution is not straight-forward to use).

But, why add a dependency on Google.Protobuf? What functionality does it bring that wouldn't be better to reimplement directly in F#? Or, conversely, if someone is already using Google.Protobuf (and the associated C# compiler), why would they use Froto? Finally, while I haven't looked at the Google code closely, John Skeet stated that adding proto2 to the current C# codebase would add lots of complexity (implying it cannot do so currently).

ctaggart added a commit that referenced this issue Jan 30, 2016
using FSharp.Core from NuGet Gallery
@ctaggart
Copy link
Owner Author

I've created froto.exe and added it to a tools package. I reserved it in the NuGet Gallery, but hid the package that I uploaded.
https://www.nuget.org/packages/Froto

To use the NuGet feed from AppVeyor, just add:
https://ci.appveyor.com/nuget/ctaggart-froto

@ctaggart
Copy link
Owner Author

I'm closing this issue. The purpose was to create the project structure, NuGet package, and register the NuGet. New issues like #15 & #17 will be for making it work. :-)

ctaggart added a commit that referenced this issue Jan 30, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants