<div dir="ltr">Looks great to me!</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/7 Erik Joelsson <span dir="ltr"><<a href="mailto:erik.joelsson@oracle.com" target="_blank">erik.joelsson@oracle.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 2013-07-26 22:40, Jonathan Gibbons wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am concerned by the preceding comment, starting line 255.<br>
<br>
255 // Always reuse -src for linking as well! This means that we might<br>
256 // get two -sourcepath on the commandline after the rewrite, which is<br>
257 // fine. We can have as many as we like.<br>
<br>
Yes, you can put as many -sourcepath options as you want, but as far as javac<br>
is concerned, "last one wins". If you want all the options to be significant in the<br>
child javac commands, you need to join the values.<br>
<br>
</blockquote></div>
I have reworded the comment, explaining that they are indeed joined later, before being handed to javac. I also added a test for the usecase I'm describing below and made the Sjavac tests runnable by jtreg.<br>
<br>
<a href="http://cr.openjdk.java.net/~erikj/8015145/webrev.langtools.02/" target="_blank">http://cr.openjdk.java.net/~<u></u>erikj/8015145/webrev.<u></u>langtools.02/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
/Erik</font></span><div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Jon<br>
<br>
On 06/07/2013 05:43 AM, Erik Joelsson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a patch solving a problem with -sourcepath for sjavac.<br>
<br>
First some background. The security sources (the ones that require signing) need to be built to a separate directory. If they aren't (as is the case now) security tests will fail if run on the exploded jdk image (the one you get when just typing make or make jdk). In JDK-8009280, I'm trying to fix this. The solution I have for that bug is working well, except when running with sjavac, and basically builds all classes except the security classes first to the normal outputdir and then as a separate step builds just the security classes to a different outputdir.<br>
<br>
There are two issues that need to be addressed in sjavac for this to work. First, it needs to be possible to supply the same source root both to the -src and -sourcepath option (but with different filter rules). Sjavac is very picky and only links to sources that are included in either of those options, and since we are excluding the security sources from -src, we need to add them to -sourcepath.<br>
<br>
The second thing is more of a bug as far as I can tell. Sjavac compares the found set of sources to compile with what the makefile think needs to be compiled, as a safety check. Currently, sjavac is including sources that are just being linked to in this comparison. I would think that it should only include sources that are meant to be compiled.<br>
<br>
<a href="http://cr.openjdk.java.net/~erikj/8015145/webrev.langtools.01/" target="_blank">http://cr.openjdk.java.net/~<u></u>erikj/8015145/webrev.<u></u>langtools.01/</a><br>
<br>
<a href="http://bugs.sun.com/view_bug.do?bug_id=8015145" target="_blank">http://bugs.sun.com/view_bug.<u></u>do?bug_id=8015145</a><br>
<br>
/Erik<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>