There are over 10**15 different paths with 5 directories from your list. And what happens if you actually need 6 of them? While I could easily produce code to enumerate them, that would be a useless approach.

Far saner would be to try removing one path at a time until you have identified only the necessary include paths. That would require 3000 steps. I believe that Java searches from the first to the last path for stuff, in which case removing the last path would be the first thing to try.

If you believe that only a small handful of these 3000 are needed, then you could do a binary search for that handful. The idea here looks something like this untested code:

{
  my @untested_blocks;
  my @needed_paths;

  sub test_all_paths {
    @needed_paths = @untested_blocks = ();
    _test_all_paths(@_);
    return @needed_paths;
  }

  sub _test_all_paths {
    my @to_test = @_;

    return unless @to_test;

    # Mark the first half as not to test.
    push @untested_blocks, [splice @to_test, 0, int(@to_test/2)];

    # Find needed blocks in second half recursively
    if (not path_works( (map @$_, @untested_blocks), @needed_paths ) {
      if (1 == @to_test) {
        push @needed_paths, @to_test;
      }
      else {
        _test_all_paths(@to_test);
      }
    }

    # Find needed paths in the untested block we just added
    _test_all_paths( @{ pop @untested_blocks } );
  }
}
[download]

If only a small fraction of your paths are needed, this will find it in a lot fewer steps.