RFR: JDK-8244844 javac command line is not re-executable

[Magnus Ihse Bursie]

On 2020-05-12 19:17, Erik Joelsson wrote:
>
> On 2020-05-12 10:08, Magnus Ihse Bursie wrote:
>> On 2020-05-12 17:38, Erik Joelsson wrote:
>>> On 2020-05-12 08:29, Magnus Ihse Bursie wrote:
>>>> We've broken our golden rule in SetupJavaCompilation, that all 
>>>> command lines should be copy/paste:able to re-execute them from the 
>>>> command line. The reason is that the file containing the source 
>>>> code file names has a temporary name, which is renamed after the 
>>>> compilation. This is just a messy way to use the file both as input 
>>>> to javac and as a marker that the compilation has succeeded. By 
>>>> splitting up these two roles, we get more readable code and a 
>>>> re-executable command line.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244844
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8244844-make-javac-re-executable/webrev.01
>>>>
>>> I really like seeing this fixed, but not sure about this patch. By 
>>> moving the filelist to a separate rule and only having the source 
>>> files as prereq, there will be cases where the source files 
>>> timestamps have not changed, but the list of files may have. I think 
>>> this would be safely covered if you moved VARDEPS_FILE as prereq to 
>>> FILELIST.
>> I see your point. Will do that.
>>
>> I was also a bit divided about whether the actual javac invocation 
>> rule should keep $$($1_SRCS) as a dependency. Technically, it's not 
>> needed, since changes in the sources will result in the filelist 
>> being updated, but maybe the intention will be better expressed. And 
>> if the set of files has not changed, then we will write the same 
>> files back to the filelist, which effectively just updates the 
>> timestamp in a roundabout way. If we keep the list of source files as 
>> dependency, we are free to implement a future optimization where the 
>> filelist is not updated if the set of files has not changed.
>>
>> Otoh, I don't know if a huge list of dependencies (the number of 
>> sources files for e.g. java.base is non-trivial!) affects make 
>> performance, so listing it twice just to make it "look good" maybe 
>> isn't a good idea.
>>
>> Do you have any opinion?
>>
> In general I like to list prereqs if they logically are direct 
> prereqs. The sources are used as input in the compilation recipe, so 
> that would be a direct prereq. If a prereq is really only transitive, 
> then I don't want to list it. I don't know what the performance impact 
> would be, I'm guessing it's not even measurable, but if it is, then 
> maybe save some processing by not adding the sources to both rules. No 
> strong opinion in this case.
Ok, I'll do it that way. I think we have generally the same preference here.

New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8244844-make-javac-re-executable/webrev.02

/Magnus
>
> /Erik
>
>> /Magnus
>>>
>>> /Erik
>>>
>>>
>>