Is proto_path of prost_build::compile_protos must be an exact prefix of the .proto file names？

[anonymousGiga]

Description:

I put my .proto file（bitswap.v1.2.0.proto） in src/schema, and write code as follows:

const PROTOS: &[&str] = &["bitswap.v1.2.0.proto"];

fn main() {
	prost_build::compile_protos(PROTOS, &["src/schema"]).unwrap();
}

In my Cargo.toml, the build depandencies is:

[build-dependencies]
prost-build = "0.11"

When I compile with protoc3.0.0, the following error occurs：

Caused by:
  process didn't exit successfully: `/home/andy/Source/main/target/debug/build/main-ff5c70b4bd71a13f/build-script-build` (exit status: 101)
  --- stdout
  Running: "/usr/bin/protoc" "--include_imports" "--include_source_info" "-o" "/tmp/prost-build8xQh7H/prost-descriptor-set" "-I" "src/schema" "bitswap.v1.2.0.proto"

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "protoc failed: bitswap.v1.2.0.proto: File does not reside within any path specified using --proto_path (or -I).  You must specify a --proto_path which encompasses this file.  Note that the proto_path must be an exact prefix of the .proto file names -- protoc is too dumb to figure out when two paths (e.g. absolute and relative) are equivalent (it's harder than you think).\n" }', build.rs:6:58

But when i compile with protoc3.20.3, no error happen.

Is proto_path must be an exact prefix of the .proto file names? If it is, why it's ok when i use protoc3.20.3?

[LucioFranco]

I believe you need to prefix the protos with the path as well. In reality, prost just passes these flags to protoc so you should be able to reproduce the protoc error via the cli directly. Prost doesn't do anything special here.

[bkchr]

I believe you need to prefix the protos with the path as well. In reality, prost just passes these flags to protoc so you should be able to reproduce the protoc error via the cli directly. Prost doesn't do anything special here.

But the docs are saying that the files should be found in the include paths? It also seems to work for most of the people, but some seem to have some special configuration or whatever where the build fails.

[bkchr]

I mean prefixing with path is fine, but then we should also update the docs.

[LucioFranco]

The docs here seem correct to me https://docs.rs/prost-build/latest/prost_build/fn.compile_protos.html#arguments but if you have any adjustments you think make sense I would love a PR!

I think we can close this issue for now since I think the main problem is resolved.

[bkchr]

includes - Paths to directories in which to search for imports. Directories are searched in order. The .proto files passed in protos must be found in one of the provided include directories.

I understand this like the files in protos should be part of the includes directory. I would expect that the paths in protos are relative to the includes directory. I mean this also works for most of the people, but just for some it fails. Is this maybe because of some version difference in protoc?

[LucioFranco]

Maybe its a protoc thing but from the cli help it doesn't specify:

$ protoc --help
Usage: protoc [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.
                              If not found in any of the these directories,
                              the --descriptor_set_in descriptors will be
                              checked for required proto file.

So I the proto path is relative to the working directory that protoc is invoked from. Iirc this should be the path that cargo build is invoked. So its not relative to the includes path but relative to the process path.

[LucioFranco]

Now could it have changed between protoc versions, totally! But I am not aware of it changing but I have also not looked super deep either.

[bkchr]

Okay, then we just change the path to include the relative path to the file.

[LucioFranco]

Ok, I think we can close this then.

[bkchr]

Yeah, thank you for your help @LucioFranco