To add more information I've discovered since I wrote that post, a modified CompilationResult also needs its set of SelectionProperty values copied, its SymbolMap will be deserialized and need to be serialized again to copy it over, and the replacement string will need to be the same length as the placeholder (or statementRanges will need to be modified...) otherwise chunking will cut off outputted js mid- statement.
While it's clear that right now CompilationResults are not intended to be modified once created (and there's a good argument that, with the js AST gone and the compilation stage finished, they shouldn't be), the "promise of Linkers" seems to be in full effect and each part of the Linker subsystem appears to only discover and read CompilationResults from the ArtifactSet pipeline. It does have the feeling of a hack at this point, mostly because of the number of hoops the code has to jump through, but it has the benefit that this Generator+Linker pair can operate and no other part of the build system need know (I think). My code seems to be working, but if anyone has any more insight, or if I'm still missing something, I would really appreciate your thoughts. Thanks. On Jan 20, 6:53 am, Brendan Kenny <bcke...@gmail.com> wrote: > I'm posting to contributors because I think I'm much more likely to > get an answer on compilation details here; I hope that's appropriate. > > If a pre-linker were to remove all CompilationResults from the > artifact set, modify the contents of string literals within their js > code (with valid results), create new StandardCompilationResults with > the modified code and new strongNames (but the same > serializedSymbolMaps, statementRanges, and permutationIds), and then > add them to the outgoing artifact set, would there be any side > effects? Would the rest of the build system (including soyc) be > disturbed at all? > > More specifically, I'm generating a Java class with a placeholder > string in it, then replacing that string in compilation results via a > (pre) Linker. The replacement string isn't known until link time, and > it's important that the resulting artifact have a strong name based in > part upon the replacement. > > The promise of Linkers seems to imply this is fine, but I can't find > any examples of a linker modifying CompilationResults and emitting > them as new CompilationResults. Obviously this process would not work > with or would miss CompilationResults which aren't > StandardCompilationResults, but that's fine for now. Are there other > assumptions/guarantees made when creating CompilationResults that > wouldn't be replicated? > > Thanks!
-- http://groups.google.com/group/Google-Web-Toolkit-Contributors
