On Tue, Jan 19, 2016 at 02:29:33PM +0100, Magnus Ihse Bursie wrote:
> On 2016-01-19 11:31, Erik Joelsson wrote:
> >Hello,
> >
> >Please review this fix in the makefiles for using sjavac. The
> >include/exclude mechanism in sjavac has changed. We used to
> >sometimes exclude files using a full absolute path. This no longer
> >works. The same thing can be achieved by splitting up the source
> >roots argument to sjavac in separate -src arguments and then
> >filter includes and excludes that are unique to a specific source
> >root. Since this risks making command lines much longer, I also
> >added a conditional ListPathsSafely/@file construct.
> >
> >Bug: https://bugs.openjdk.java.net/browse/JDK-8147449
> >Webrev: http://cr.openjdk.java.net/~erikj/8147449/webrev.01/
> 
> It's a bit head-ache-inducing (not your fault, though!) but it looks
> correct to me.

To summarize the discussion Erik and I had on this topic...

Enabling absolute paths in the include/exclude patterns is a bit problematic 
unfortunately. The reason behind this is that sjavac would have to figure out 
if the absolute or relative path of a file sohuld be used in the 
include/exclude check. This decision would depend on whether the pattern is 
absolute or relative. Trying to pin down what an "absolute pattern" means is 
tricky though. To make a long story short, consider for example 
"{/home,foo}/bar". (Before the include/exclude rewrite we had -i, -if, -x and 
-xf to distinguish the cases. This was a mess. The wildcard had different 
semantics for the different switches for instance.)

An alternavite route that I and Erik briefly discussed was to rely on explicit 
listing of the files instead, as we do for javac (and maybe even drop the 
include/exclude mechanism). This has a couple of pros'n'cons and is a subject 
of a larger discussion that I think we can have at a later point.

-- Andreas

Reply via email to