[ 
https://issues.apache.org/jira/browse/THRIFT-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416508#comment-16416508
 ] 

Buğra Gedik commented on THRIFT-4532:
-------------------------------------

We considered two approaches. The first one was just what you described. 
Generate the target file into a temp directory, and if it turns out to be the 
same as the existing one in the output directory, just discard the temporary. 
Otherwise, move it over.

The second one was including a signature into the generated files, like the 
hash of the source thrift file(s) that have contributed to its generation. 
However, given the inclusion support and cross-file referencing, it seems to me 
that a generated file is not necessarily dependent on just one thrift file and 
in the case of mutliple thrift files, using all may cause regenerating 
unnecessarily, as not all entities from an included thrift file would be used.

So it seems like the first approach is more practical, even though it results 
in re-running the code generation logic. In any case, what we care about is the 
generated files, as the most time consuming part is compiling them, especially 
in the case of C++.

 

 

> Avoid updating Thrift compiler generated code if the output has not changed
> ---------------------------------------------------------------------------
>
>                 Key: THRIFT-4532
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4532
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Compiler (General)
>    Affects Versions: 0.11.0
>            Reporter: Buğra Gedik
>            Priority: Minor
>             Fix For: 0.12.0
>
>
> We would like to contribute an improvement to the Thrift compiler that would 
> avoid regenerating target file(s) if they are going to be exactly the same as 
> the ones already present in the same place. This will help when running the 
> Thrift compiler in our build, especially in recursive mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to