On Thu, Feb 11, 2010 at 8:58 PM, Brendan Kenny <[email protected]> wrote: > > If this is indeed the direction to go in (and I'm a big fan of the > goals as well), it's probably also worth making a more formal > definition for "won't step on each other's toes". As a use case, I'm > working on a PRE linker that (currently) removes CompilationResults, > alters them based on information collected from across all > permutations, and then emits new ones. Obviously this isn't ideal--its > expensive and CompilationResults were written to be (mostly) > immutable--but it's also perfectly acceptable within the current > design of the artifactSet/linker chain. The primary linker only cares > about the set of compilation results it receives, and if an earlier > linker altered them, it need never know. >
Hey, Brendan, it sounds like you are already pressing the limits of what is doable with linkers. Can you describe in more detail what this linker accomplishes? For this linker to be used in distributed builds, I believe you'd really want to come up with a way to do the JS rewrites on the sharded part. Otherwise, the final link node is going to have to do the JS rewrites for the whole build sequentially. What exact information is used as input to the rewrites? > It seems (and I could definitely be misinterpreting here) that in both > the simulated sharding procedure and Scott's alternate proposal, there > will be sections of primary and post linkers running before a non- > shardable pre linker. If that's true, then neither will be able to > fully honor the ordering of linkers when shardable and non-shardable > linkers are mixed. That's a large part of why I suggested that we phase out non-sharded linkers. In mixed mode, there isn't a perfect ordering to choose. With all sharded linkers, the order is simple and predictable. All sharded parts run before all final parts, and within either of those groups, PRE/PRIMARY/POST are respected. > Continuing to think out loud, it seems that the way to alter my linker > is probably either to statically derive what all permutations will > need in every shard (as opposed to just having each triggered > generator emit an artifact and collecting them at the end), or keeping > that the same and creating a custom primary linker, which I was hoping > not to do as it would tend to limit adoption. > It might help to know that both generators and linkers have access to the full set of *possible* values of a deferred binding, not just the values for the current permutation. As an example, the LocaleListLinker reads off all possible values of "locale" and generates a file containing them: http://code.google.com/p/google-web-toolkit-incubator/source/browse/trunk/src/com/google/gwt/libideas/linker/LocaleListLinker.java Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
