On Mon, 2012-08-06 at 17:27 -0700, Christian Hammond wrote:
> Going further, if that change is reverted, the next failure seems to
> come from when they redid the compiler API. What's odd is that the
> code doesn't look like it should be an issue, but the bisects keep
> pointing to it. This is revision
> 96b356d7c9a8e5626b4ce018577984b89c7f2178.

>From further investigation, it looks like that patch was completely
broken until they added both c1ff4867fe57a9fffbddae38b51d888c85304a87
and fb51fba3f391a9685f4ab65757e7511e3f927df8 to fix it properly. So
we're probably getting a false-positive from git bisect because those
two patches are also not included. Maybe a quick 'git rebase -i' to
merge those into 96b356d7c9a8e5626b4ce018577984b89c7f2178 will allow git
bisect to find the real culprit?

The only other thing I noticed was that they did change behavior in one
place in that code. In Compiler.compile(), they were previously passing
"output_path" to the compilers as the output argument, but this patch
changes that to be "output_file" as determined by finders.find(). Being
unfamiliar with the code and the return type of finders.find(), I can't
say whether this is relevant.

Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to