RFR: 8010465: Can't enable sjavac when building in jprt.

[Anthony Petrov]

Thanks for clarifying that. Makes sense to me.

The fix looks good to me, btw, although I'm not a build expert.

Also, could you clarify why do Windows builds fail with sjavac? Is this 
a known bug in sjavac or the build system?

--
best regards,
Anthony

On 04/08/13 17:03, Erik Joelsson wrote:
> Sjavac also enables parallel execution of java compilation, speeding up
> full builds as well. But even if it didn't, being able to verify that
> sjavac builds work in jprt will be a must if we are to enable it by
> default.
>
> /Erik
>
> On 2013-04-08 14:56, Anthony Petrov wrote:
>> Just curious: sjavac is supposed to address the issue with slow
>> incremental builds. JPRT builds are full builds usually. What is the
>> benefit of using sjavac for full builds?
>>
>> --
>> best regards,
>> Anthony
>>
>> On 04/08/13 13:44, Erik Joelsson wrote:
>>> Reminder that I would like this reviewed.
>>>
>>> /Erik
>>>
>>> On 2013-03-21 12:49, Erik Joelsson wrote:
>>>> This patch makes it possible to enable sjavac in jprt runs. This is
>>>> achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command
>>>> line.
>>>>
>>>> http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/
>>>>
>>>> Doing this uncovered another bug. Adding the keyword "nofile" to the
>>>> LOG variable is done to disable logging build output to a file. JPRT
>>>> does this on all build runs since it already saves the build output.
>>>> The value of LOG is also sent to sjavac to help it filter its output,
>>>> but sjavac does not accept "nofile" as input. The logic to remove
>>>> "nofile" before sending it to sjavac didn't work and is also fixed in
>>>> this patch.
>>>>
>>>> The sad news is that all the windows builds currently fail with sjavac
>>>> enabled, but having this feature will help us harden sjavac to the
>>>> point where we can make the switch.
>>>>
>>>> /Erik
>>>>
>>>>