protoc-c command is wrapped and executed automatically if --c_out= is specified, if some other output directive is specified(e.g. --ruby_out), the wrapper will invoke both protoc-c and protoc with appropriate directives.
Currently it's possible to compile for following languages:
C
C++
C#
Java
JavaScript
Go
Objective-C
PHP
Python
Ruby
Swift
I'll implement missing language support in the next step (#15)
I added a protos build target to be consistent with naming of other build targets,
I changed the way we determine GOPATH, with this implementation, as long as the package is located at <somepath>/src/github.com/TheThingsNetwork/api and the user has docker and git installed, it will be possible to compile out protos, no go or specific environment variables needed
Not sure how we can make compiled protos from CI end up in the repo. Giving write access to the CI is probably not the best idea. We could make releases. I added a very simple travis.yml, it regenerates all compiled code and fails if diff with HEAD is non-empty. Therefore protos/mocks should be compiled on dev machine, while CI would check the output.
You will notice some file removals:
There were some java files included in the repo, which seem to be located in the wrong place(whey also exist in the expected locations). For example,java/src/lorawan/DevAddrManagerGrpc.java was duplicated at org/thethingsnetwork/api/protocol/lorawan/DevAddrManagerGrpc.java
Changes in the protos/mocks is due to the change in versions - the image uses the latest tagged versions of packages(excluding go, which are go get'ed from master)
Closes #1
Created a https://github.com/TheThingsIndustries/docker-protobuf
protoc
Docker image, which containsprotoc
protoc-c
gogottn
pluginprotoc-c
command is wrapped and executed automatically if--c_out=
is specified, if some other output directive is specified(e.g.--ruby_out
), the wrapper will invoke bothprotoc-c
andprotoc
with appropriate directives.Currently it's possible to compile for following languages:
I'll implement missing language support in the next step (#15)
I added a
protos
build target to be consistent with naming of other build targets, I changed the way we determineGOPATH
, with this implementation, as long as the package is located at<somepath>/src/github.com/TheThingsNetwork/api
and the user hasdocker
andgit
installed, it will be possible to compile out protos, nogo
or specific environment variables neededNot sure how we can make compiled protos from CI end up in the repo. Giving write access to the CI is probably not the best idea. We could make releases. I added a very simple
travis.yml
, it regenerates all compiled code and fails ifdiff
withHEAD
is non-empty. Therefore protos/mocks should be compiled on dev machine, while CI would check the output.You will notice some file removals: There were some
java
files included in the repo, which seem to be located in the wrong place(whey also exist in the expected locations). For example,java/src/lorawan/DevAddrManagerGrpc.java
was duplicated atorg/thethingsnetwork/api/protocol/lorawan/DevAddrManagerGrpc.java
Changes in the protos/mocks is due to the change in versions - the image uses the latest tagged versions of packages(excluding
go
, which arego get
'ed frommaster
) Closes #1