Fix antlr sources
Review Request #679 - Created July 15, 2014 and submitted
|areitz, jsirois, tejal|
This fixes an issue where CacheValidator's source hashing was failing on the synthetic targets generated by AntlrGen, since the assumed source paths mismatched the actual generated paths. - Adds an integration test for antlr4 codegen - Uses sources_relative_to_buildroot for the assumed output sources, since we can't control antlr's output relative paths very tightly without changing directories (which would circumvent nailgun)
new and existing test(s)
LGTM mod source_roots on the synthetic targets are wrong fwict. The test seems to back this up, accepting synthetic target sources as src/java/...[more]... instead of ...[more]...
This is suspect now for the source jar packaging case: self.context.add_new_target sets up a source_root at address.spec_path, so here thats, say .pants.d/gen/antlr4. Now sources_relative_to_buildroot nets for an input of src/antlr/com/twitter/parser/grammar.g an output of src/antlr/com/twitter/parser/grammar/Lexer.java in the accumulated generated_sources. This helps find the generated java file at .pants.d/gen/antlr4/src/antlr/com/twitter/parser/grammar/Lexer.java - but it does so with the wrong source_root and a source jar will contain src/antlr/com/twitter/parser/grammar/Lexer.java instead of com/twitter/parser/grammar/Lexer.java. So the source_root of the input needs to be added to the synthetic target address spec_path and subtracted from the collected generated_sources to net the same full path (relative to the buildroot), but divided correctly just after .pants.d/gen/antlr4/src/antlr
Review request changed
Fix for the issue John saw. Thanks! - Switched back to using sources_relative_to_source_root for the generated sources, but propagated the input source root to the destination.