#general
- b
bored-art-40741
10/05/2015, 5:23 PMWe got rid of compile time exclusions on JvmTarget right? - b
bored-art-40741
10/05/2015, 5:24 PMSo the actual subgraph that we consider is quite restricted - w
witty-crayon-22786
10/05/2015, 5:24 PMno, they're there. but they work "correctly" now - b
bored-art-40741
10/05/2015, 5:24 PMAh - b
bored-art-40741
10/05/2015, 5:24 PMIt's still quite restrictive because most JvmTargets don't actually define them - b
bored-art-40741
10/05/2015, 5:25 PMAlso I'm not talking about runtime_excludes, to be clear - w
witty-crayon-22786
10/05/2015, 5:25 PMbut the base case is util-core - b
bored-art-40741
10/05/2015, 5:25 PMOnly compile time - w
witty-crayon-22786
10/05/2015, 5:25 PMit doesn't have any dependencies - w
witty-crayon-22786
10/05/2015, 5:25 PMbut when it is included in other targets, it should not be recompiled - b
bored-art-40741
10/05/2015, 5:25 PMre-resolved? - b
bored-art-40741
10/05/2015, 5:26 PMI think it's time for us to define a concrete graph we're interested in - b
bored-art-40741
10/05/2015, 5:26 PMIt's worth noting how even very large graphs decompose to very small ones under my proposal - b
bored-art-40741
10/05/2015, 5:27 PMSo the number of subgraphs that you re-resolve during thrash is very small, and thrash only happens when you (1) change 3rdparty build or (2) Change excludes on a jvm_target that's within the subgraph you're compiling - b
bored-art-40741
10/05/2015, 5:27 PMIn other words, the exact same way that IvyResolve's fingerprint strategy works today! - b
bored-art-40741
10/05/2015, 5:27 PMIt's isomorphic to making FP strats transitive in the task graph - b
bored-art-40741
10/05/2015, 5:28 PMBut I think it models the problem more directly (it's really an issue with the keyspace of
, not other products).compile_classpath - w
witty-crayon-22786
10/05/2015, 5:28 PMre (2): now it affects your dependees, not your dependencies - b
bored-art-40741
10/05/2015, 5:28 PMAgreed - b
bored-art-40741
10/05/2015, 5:28 PMBut that's expected when you change a target - b
bored-art-40741
10/05/2015, 5:29 PMYou always cause invalidation up rather than down - b
bored-art-40741
10/05/2015, 5:29 PMWell, depending on how you define your directions... - b
bored-art-40741
10/05/2015, 5:30 PMReally though I think this is isomorphic to your proposed solution, so I think we're on the same page. But I'd like to convince you that it's really about the keyspace of
and not a general issue with FP Stratsclasspath_products - b
bored-art-40741
10/05/2015, 5:30 PMGotta hit a 1:1, back to chat in a while - w
witty-crayon-22786
10/05/2015, 5:35 PMyou know what... i think the hashing of products that exists in bazel is actually just optimization... so they hash inputs, and they short-circuit if an output hash matches - w
witty-crayon-22786
10/05/2015, 5:36 PMthat would still not be awesome for this case without some change in ivy though. you'd recompile everything, and only begin to short circuit after compilation - f
fancy-queen-20734
10/05/2015, 5:40 PMHave we looked at using confs to break up ivy resolves by target? - w
witty-crayon-22786
10/05/2015, 5:43 PMwouldn't that lose us the feature that the compile time classpath matches the runtime classpath? - f
fancy-queen-20734
10/05/2015, 5:44 PMDepending on how ivy does things, we might be able to still get the perf win of having one ivy invocation, while also ensuring that resolves are deterministic for a given subgraph - f
fancy-queen-20734
10/05/2015, 5:45 PMwell, now that we’re further abstracting away from ivy’s model, we don’t have to maintain a 1:1 correspondence with how we configure ivy to go out and resolve things