Analyzer build updates to use analyzer_cli.

Analyzer build updates to use analyzer_cli.

The associated change to add analyzer_cli to DEPS is here:
https://codereview.chromium.org/1093173004/

R=brianwilkerson@google.com, paulberry@google.com, ricow@google.com, rnystrom@google.com

Committed: https://code.google.com/p/dart/source/detail?r=45321

[pquitslund, 2015-04-20 21:04:36]

pquitslund@google.com changed reviewers:
+ paulberry@google.com, ricow@chromium.org, rnystrom@google.com

[pquitslund, 2015-04-20 21:04:37]

I've asked for a bunch of eyes on this one since it pays to get this especially
right. :)

[pquitslund, 2015-04-20 21:04:54]

pquitslund@google.com changed reviewers:
+ brianwilkerson@google.com

[Brian Wilkerson, 2015-04-20 21:07:02]

LGTM, but I have no idea whether it's right

[Paul Berry, 2015-04-20 21:22:08]

lgtm, except that I'm confused about what "pkg_tested" means.  My understanding
from talking to Phil is that "pkg_tested" is the home for packages that live
outside the repo but need to have their tests run by the buildbots, and
furthermore that when those tests are run by the buildbots, they should be run
using the "packags" directory that is generated by the build process, so that
the tests are run against the bleeding edge version of the depended-upon
packages rather than the versions of those packages specified in the pubspec.

But what I don't understand is, I thought that was what we were already doing on
the buildbots for the "pkg" directory, so I'm not sure how this is different. 
Is it possible that "pkg_tests" is intended for packages which the SDK *doesn't*
depend upon, but which we want to make sure don't get broken when the SDK is
changed?  If that's the case, then shouldn't the command-line analyzer should go
in pkg, not pkg_tests, because the analyzer gets built and shipped as part of
the SDK?

And for that matter, since the analysis server is shipped as part of the SDK,
and the analysis server depends on dart_style, wouldn't that mean that
dart_style should go in pkg as well?

[Bob Nystrom, 2015-04-20 22:54:53]

On 2015/04/20 21:22:08, Paul Berry wrote:
> lgtm, except that I'm confused about what "pkg_tested" means.  My
understanding
> from talking to Phil is that "pkg_tested" is the home for packages that live
> outside the repo but need to have their tests run by the buildbots, and
> furthermore that when those tests are run by the buildbots, they should be run
> using the "packags" directory that is generated by the build process, so that
> the tests are run against the bleeding edge version of the depended-upon
> packages rather than the versions of those packages specified in the pubspec.
> 
> But what I don't understand is, I thought that was what we were already doing
on
> the buildbots for the "pkg" directory, so I'm not sure how this is different. 

/pkg/ is where packages that *live* in the repo exist, and those packages are
tested on the bots like you describe.

Other packages that live in their own repos on GitHub are brought into
/third_party/pkg/. These don't get their tests run on the bots using the
bleeding edge "packages" directory. (They are tested on the package bots. That
uses pub get to let each package get its own dependencies.)

/third_party/pkg_tested/ is a weird third case where the package lives outside
of the repo but ships in the SDK so we want to test it against the other
bleeding edge code that will ship in the SDK.

Does that help?

- bob

[Bob Nystrom, 2015-04-20 22:55:37]

LGTM. I assume you also have (unchanged) analyzer_sdk scripts that run the
snapshot version when run from the built SDK?

[pquitslund, 2015-04-20 22:57:19]

On 2015/04/20 22:55:37, Bob Nystrom wrote:
> LGTM. I assume you also have (unchanged) analyzer_sdk scripts that run the
> snapshot version when run from the built SDK?

Correct.  Happily, nothing to change there.

[Paul Berry, 2015-04-20 22:57:43]

On 2015/04/20 22:54:53, Bob Nystrom wrote:
> On 2015/04/20 21:22:08, Paul Berry wrote:
> > lgtm, except that I'm confused about what "pkg_tested" means.  My
> understanding
> > from talking to Phil is that "pkg_tested" is the home for packages that live
> > outside the repo but need to have their tests run by the buildbots, and
> > furthermore that when those tests are run by the buildbots, they should be
run
> > using the "packags" directory that is generated by the build process, so
that
> > the tests are run against the bleeding edge version of the depended-upon
> > packages rather than the versions of those packages specified in the
pubspec.
> > 
> > But what I don't understand is, I thought that was what we were already
doing
> on
> > the buildbots for the "pkg" directory, so I'm not sure how this is
different. 
> 
> /pkg/ is where packages that *live* in the repo exist, and those packages are
> tested on the bots like you describe.
> 
> Other packages that live in their own repos on GitHub are brought into
> /third_party/pkg/. These don't get their tests run on the bots using the
> bleeding edge "packages" directory. (They are tested on the package bots. That
> uses pub get to let each package get its own dependencies.)
> 
> /third_party/pkg_tested/ is a weird third case where the package lives outside
> of the repo but ships in the SDK so we want to test it against the other
> bleeding edge code that will ship in the SDK.
> 
> Does that help?
> 
> - bob

Yes.  Thanks for the clarification, Bob.  Lgtm as is.

[ricow1, 2015-04-21 06:12:09]

ricow@google.com changed reviewers:
+ ricow@google.com

[ricow1, 2015-04-21 06:12:09]

lgtm (and thanks to Bob for very accurately laying out the structure of the pkg
locations)

[pquitslund, 2015-04-21 20:59:38]

Committed patchset #2 (id:20001) manually as r45321 (presubmit successful).