On Mon, Jan 8, 2018 at 2:07 PM, Bo Yang <[email protected]> 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 <[email protected]>
> 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 <[email protected]> wrote:
>>
>>> 1. This is the original PR to implement the feature:
>>> https://github.com/google/protobuf/commit/532c94145b66053615
>>> 13682601f1d8e9f97a2497
>>> 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 <[email protected]> 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 <[email protected]> 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 [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at https://groups.google.com/group/protobuf.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to