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

[Fredrik Öhrström]

Smarta javac collects all -sourcepaths and concatenates them into a single
one before passing the command line to plain javac.

Thus "-sourcepath /foo -sourcepath /bar" becomes "-sourcepath /foo:/bar"

//Fredrik


2013/7/26 Jonathan Gibbons <jonathan.gibbons at oracle.com>

> 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.
>
> -- 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/20130728/ad93c57d/attachment.html