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

[Erik Joelsson]

Looks good.

/Erik

On 2020-05-12 10:32, Magnus Ihse Bursie wrote:
>
>
> 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
>>>>
>>>>
>>>
>