[quietbritishjim]

Sorry I didn't call this out more clearly, but I think the server-hot vs hot-server thing is a typo in the readme that's wrong on any platform.

Looking forward to include path support. I tried flattening my protos into one directory, updated all their `import` directives and gave it a go, and it works great, thanks! Both client and server running on Windows. My protos use a well known type (google.protobuf.Duration) and I was particularly impressed that it worked without me having to copy in the proto file for that.

I'm sure you already know this, but just in case: Include paths don't just help with proto files scattered across different directories, they also allow part of the path to be part of the canonical name of the proto. [1, 2] For example, if you have these files:

    /
        src/
            xyz/
                foo.proto   # Contains: import "xyz/bar.proto"
                bar.proto

Then you need -I/src (or similar) because if you run protoc from within /src/xyz/ without -I then it's like you specified -I/src/xyz, and then foo.proto can't find bar.proto (because it looks for /src/xyz/xyz/bar.proto). Using relative paths like this is useful because you can have proto files with the same file name (like "config.proto") so long as their full canonical name is different, and because generated files are output into corresponding subdirectories (which is especially useful in Python where the subdirectory indicates the package name).

[1] https://stackoverflow.com/questions/18735609/the-path-in-pro...

[2] https://github.com/protocolbuffers/protobuf/issues/723#issue...