protoc input dependency checking (--dependency_out)

[Arpit Baldeva]

Hi,

I tried using --dependency_out option and ran into a few issues.

1. It does not work with multiple files input. Are there any plans to add that support? 
   
2. I noticed that the dependency file includes the whole dependency chain from other proto files. I am not sure if it is necessary. So if there is foo.proto that includes bar.proto and someone makes a change in bar.proto, I don't think generating code for foo.proto is a necessity. Is there something I am missing here?
3. The option actually did not work for me. But I did not dig into it too much because I wanted to figure out 1&2 first.

Thanks.

[Bo Yang]

1. This is the original PR to implement the feature: https://github.com/google/protobuf/commit/532c94145b6605361513682601f1d8e9f97a2497

I don't think there is technical issue to block supporting multiple input files. However, we don't have plan to implement that yet. You are welcome to contribute. 

2. I remember we just want to be protective when we implement this feature. +Thomas Van Lenten Do you remember any specific reason we need full closure dependency of generated files?

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Thomas Van Lenten]

The intent was to make it easier to hook things into build systems, i.e. - you could get something like C/C++ compilers can do to generate a .d file you can -include to force sources to regenerate when a input proto changes.  I think the only reason it was single file was simplicity (and from a build system pov, you usually only want to reissue the command for the things that changed, so one at a time).

TVL

On Mon, Jan 8, 2018 at 1:58 PM, Bo Yang <tebo...@google.com> wrote:

1. This is the original PR to implement the feature: https://github.com/google/protobuf/commit/532c94145b6605361513682601f1d8e9f97a2497

I don't think there is technical issue to block supporting multiple input files. However, we don't have plan to implement that yet. You are welcome to contribute. 

2. I remember we just want to be protective when we implement this feature. +Thomas Van Lenten Do you remember any specific reason we need full closure dependency of generated files?

On Thu, Jan 4, 2018 at 3:25 PM Arpit Baldeva <abal...@gmail.com> wrote:

Hi,

I tried using --dependency_out option and ran into a few issues.

1. It does not work with multiple files input. Are there any plans to add that support? 
   
2. I noticed that the dependency file includes the whole dependency chain from other proto files. I am not sure if it is necessary. So if there is foo.proto that includes bar.proto and someone makes a change in bar.proto, I don't think generating code for foo.proto is a necessity. Is there something I am missing here?
3. The option actually did not work for me. But I did not dig into it too much because I wanted to figure out 1&2 first.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscribe@googlegroups.com.

[Bo Yang]

@thomas, for question 2, do you remember any reason? It seems to me only direct dependencies of generated files are useful. Is current way over-protective?

On Mon, Jan 8, 2018 at 11:02 AM Thomas Van Lenten <thom...@google.com> wrote:

The intent was to make it easier to hook things into build systems, i.e. - you could get something like C/C++ compilers can do to generate a .d file you can -include to force sources to regenerate when a input proto changes.  I think the only reason it was single file was simplicity (and from a build system pov, you usually only want to reissue the command for the things that changed, so one at a time).

TVL

On Mon, Jan 8, 2018 at 1:58 PM, Bo Yang <tebo...@google.com> wrote:

1. This is the original PR to implement the feature: https://github.com/google/protobuf/commit/532c94145b6605361513682601f1d8e9f97a2497

I don't think there is technical issue to block supporting multiple input files. However, we don't have plan to implement that yet. You are welcome to contribute. 

2. I remember we just want to be protective when we implement this feature. +Thomas Van Lenten Do you remember any specific reason we need full closure dependency of generated files?

On Thu, Jan 4, 2018 at 3:25 PM Arpit Baldeva <abal...@gmail.com> wrote:

Hi,

I tried using --dependency_out option and ran into a few issues.

1. It does not work with multiple files input. Are there any plans to add that support? 
   
2. I noticed that the dependency file includes the whole dependency chain from other proto files. I am not sure if it is necessary. So if there is foo.proto that includes bar.proto and someone makes a change in bar.proto, I don't think generating code for foo.proto is a necessity. Is there something I am missing here?
3. The option actually did not work for me. But I did not dig into it too much because I wanted to figure out 1&2 first.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.

[Thomas Van Lenten]

On Mon, Jan 8, 2018 at 2:07 PM, Bo Yang <tebo...@google.com> wrote:

@thomas, for question 2, do you remember any reason? It seems to me only direct dependencies of generated files are useful. Is current way over-protective?

My guess would be because we don't know exactly what all the generators capture in the generated source.  If one captured something about a transitive type (say for an extension registry, enum value, etc.), then might need to regenerate because of that change.  Same reason C/C++ compilers capture the transitive dep, it gets to hard to tell if it changes this output or not.

TVL

 

On Mon, Jan 8, 2018 at 11:02 AM Thomas Van Lenten <thom...@google.com> wrote:

The intent was to make it easier to hook things into build systems, i.e. - you could get something like C/C++ compilers can do to generate a .d file you can -include to force sources to regenerate when a input proto changes.  I think the only reason it was single file was simplicity (and from a build system pov, you usually only want to reissue the command for the things that changed, so one at a time).

TVL

On Mon, Jan 8, 2018 at 1:58 PM, Bo Yang <tebo...@google.com> wrote:

1. This is the original PR to implement the feature: https://github.com/google/protobuf/commit/532c94145b6605361513682601f1d8e9f97a2497

I don't think there is technical issue to block supporting multiple input files. However, we don't have plan to implement that yet. You are welcome to contribute. 

2. I remember we just want to be protective when we implement this feature. +Thomas Van Lenten Do you remember any specific reason we need full closure dependency of generated files?

On Thu, Jan 4, 2018 at 3:25 PM Arpit Baldeva <abal...@gmail.com> wrote:

Hi,

I tried using --dependency_out option and ran into a few issues.

1. It does not work with multiple files input. Are there any plans to add that support? 
   
2. I noticed that the dependency file includes the whole dependency chain from other proto files. I am not sure if it is necessary. So if there is foo.proto that includes bar.proto and someone makes a change in bar.proto, I don't think generating code for foo.proto is a necessity. Is there something I am missing here?
3. The option actually did not work for me. But I did not dig into it too much because I wanted to figure out 1&2 first.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscribe@googlegroups.com.