Closed tony612 closed 4 years ago
@tony612 can you try a quick patch, which is calling Code.ensure_loaded(type)
before calling type.key(1)
in the changes made in my PR?
@whatyouhide I tried, but only using ensure_loaded
doesn't work. I think it's because we have a file like this
defmodule Foo.Msg do
use Protobuf, syntax: :proto3
field :type, 0, type: Foo.Enum, enum: true
end
defmodule Foo.Enum do
use Protobuf, enum: true, syntax: :proto3
field :UNKNOWN, 0
end
And Elixir can't compile a file like this, we have to write a file like
defmodule Foo.Enum do
use Protobuf, enum: true, syntax: :proto3
field :UNKNOWN, 0
end
defmodule Foo.Msg do
use Protobuf, syntax: :proto3
field :type, 0, type: Foo.Enum, enum: true
end
I tried adjuting the ordering of the generated code in this branch https://github.com/tony612/protobuf-elixir/compare/fix-gen-order?expand=1
This branch just put enum in the first in generated files, I'm not sure if this can cover every case, but our protos can be compiled successfully with it.
@tony612 looks good to me :)
I am having issues with this on 0.7.1
.
I am having an issue with enums defined in the same file are being generated at the bottom of the file. My work around is to move them to the top of the file but that has to be done every time we regenerate them.
@whatyouhide @tony612
@mackeyja92 Could you regenerate the code after upgrading protoc plugin?
mix escript.install hex protobuf 0.7.1
The escript version is different from the protobuf
version in mix.exs.
@tony612 Yes. That solved it for me. Thank you!
It seems this is caused by this PR. I guess the reason is
Content.Foo
is defined at another file, and with this PR's change,Content.Foo
is not compiled when compilingContent.Bar
.