On 2013-04-08 15:17, Anthony Petrov wrote:
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?
It looks to me like a bug in sjavac. I have seen it work previously.
/Erik
--
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
