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

[Fredrik Öhrström]

This looks good! It was a use case that I did not anticipate, i.e. use the
same source
root with different filtering rules. Can you add test case
to langtools/test/tools/sjavac/SJavac.java ?
That would be great!

//Fredrik


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

> 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/20130712/70fccac4/attachment-0001.html