RFR: 8015145: Smartjavac needs more flexibility with linking to sources

[Fredrik Öhrström]

Looks great to me!


2013/8/7 Erik Joelsson <erik.joelsson at oracle.com>

>
>
> On 2013-07-26 22:40, Jonathan Gibbons wrote:
>
>> I am concerned by the preceding comment, starting line 255.
>>
>>  255             // Always reuse -src for linking as well! This means
>> that we might
>>  256             // get two -sourcepath on the commandline after the
>> rewrite, which is
>>  257             // fine. We can have as many as we like.
>>
>> Yes, you can put as many -sourcepath options as you want, but as far as
>> javac
>> is concerned, "last one wins". If you want all the options to be
>> significant in the
>> child javac commands, you need to join the values.
>>
>>  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.
>
> http://cr.openjdk.java.net/~**erikj/8015145/webrev.**langtools.02/<http://cr.openjdk.java.net/~erikj/8015145/webrev.langtools.02/>
>
> /Erik
>
>  -- Jon
>>
>> On 06/07/2013 05:43 AM, Erik Joelsson wrote:
>>
>>> Here is a patch solving a problem with -sourcepath for sjavac.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> http://cr.openjdk.java.net/~**erikj/8015145/webrev.**langtools.01/<http://cr.openjdk.java.net/~erikj/8015145/webrev.langtools.01/>
>>>
>>> http://bugs.sun.com/view_bug.**do?bug_id=8015145<http://bugs.sun.com/view_bug.do?bug_id=8015145>
>>>
>>> /Erik
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130811/8ba91054/attachment.html