Reenable test.dart to be invoked from dartium checkout

Reenable test.dart to be invoked from dartium checkout

This will be used to remove the Dartium usage of minfrog.  From a dartium enlistment, the following will work.

To test with frog:

./dart/tools/test.py --compiler=frog --frog=/usr/local/google/vsm/git/src/dart/frog/frogc.dart --shell=./out/Release/dart --runtime=drt --drt=./out/Release/DumpRenderTree --mode=release client/html

To test with dart2js:

./dart/tools/test.py --compiler=dart2js --frog=/usr/local/google/vsm/git/src/dart/frog/frogc.dart --shell=./out/Release/dart --runtime=drt --drt=./out/Release/DumpRenderTree --mode=release client/html

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

[ahe, 2012-04-24 08:52:57]

LGTM!

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
File tools/testing/dart/test_options.dart (right):

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
tools/testing/dart/test_options.dart:229: ['--shell'],
It feels weird calling this argument "shell". One alternative suggestion is
"vm-binary".

[ahe, 2012-04-24 08:53:26]

Perhaps Bill has something to add.

[Bill Hesse, 2012-04-24 09:28:25]

Consider just fixing the build path computation instead - then the shell path is
computed correctly automatically.

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
File tools/testing/dart/test_options.dart (right):

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
tools/testing/dart/test_options.dart:229: ['--shell'],
On 2012/04/24 08:52:57, ahe wrote:
> It feels weird calling this argument "shell". One alternative suggestion is
> "vm-binary".

Søren and I also don't like "shell".  I think just --dart is a great name.  It
is the location of dart.  The dart program.  The dart executable.

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
File tools/testing/dart/test_suite.dart (right):

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
tools/testing/dart/test_suite.dart:1267: name =
'${buildDir(configuration)}/${executableName(configuration)}';
The real problem is that the buildDir is not correct - it is out/Release_ia32
rather than out/Release.  I would prefer much more that you either make the
buildDir(configuration) helper function find the right directory automatically,
by checking which one exists, or else that you introduce a --build-dir flag,
which overrides the calculated build directory.  That would fix both the dart
executable and the drt paths, I think.  I am ok with the --dart flag (instead of
--shell), but it won't be needed if you have --build-dir instead, or if build
dir is computed automatically.

[vsm, 2012-04-24 16:05:57]

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
File tools/testing/dart/test_options.dart (right):

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
tools/testing/dart/test_options.dart:229: ['--shell'],
On 2012/04/24 08:52:57, ahe wrote:
> It feels weird calling this argument "shell". One alternative suggestion is
> "vm-binary".

Done.

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
File tools/testing/dart/test_suite.dart (right):

https://chromiumcodereview.appspot.com/10201005/diff/1/tools/testing/dart/tes...
tools/testing/dart/test_suite.dart:1267: name =
'${buildDir(configuration)}/${executableName(configuration)}';
It's a little more complicated than that.  In an all.deps enlistment, DRT is
downloaded on demand to:
./client/tests/drt
In a Dartium enlistment, that actually works fine, but you of course want to use
the DRT you built under out/Release.

For the compiler (frog), in an all.deps enlistment, a compiler "executable" is
placed under out/Release_ia32/frog/bin/frog - which is what the tests use.  In a
Dartium enlistment, we don't build frog (we'd have to change chrome trunk's gyp
to do it), so this change invokes the compiler via the vm.

The VM is the one thing out of the three that is actually built in both
enlistments.

On 2012/04/24 09:28:25, Bill Hesse wrote:
> The real problem is that the buildDir is not correct - it is out/Release_ia32
> rather than out/Release.  I would prefer much more that you either make the
> buildDir(configuration) helper function find the right directory
automatically,
> by checking which one exists, or else that you introduce a --build-dir flag,
> which overrides the calculated build directory.  That would fix both the dart
> executable and the drt paths, I think.  I am ok with the --dart flag (instead
of
> --shell), but it won't be needed if you have --build-dir instead, or if build
> dir is computed automatically.

[Bill Hesse, 2012-04-24 16:10:13]

OK, well if there is no solution that does more for you automatically, the
letting the dart standalone location be specified via --dart is fine.  LGTM.

[Bill Hesse, 2012-04-24 16:10:38]

On 2012/04/24 16:10:13, Bill Hesse wrote:
> OK, well if there is no solution that does more for you automatically, the
> letting the dart standalone location be specified via --dart is fine.  LGTM.

or --vm-binary.

[vsm, 2012-04-24 16:33:06]

Thanks for the reviews.  Landed with the --dart flag.