Hi everyone,

I'm working on a new test driver script (i.e. replacement for
tools/test.py) that'll be faster and generally better. In doing so, I have
discovered a few options/features of test.py that to my knowledge are not
being used currently, so I'd like to avoid the effort of keeping them alive
unless someone does need them. To be clear: I'm not planning to break any
feature that's being used, but I do want to avoid wasting time on stuff
that nobody uses. So: *If you use any of the following options to
tools/test.py and would like to keep doing so, please speak up now or they
will go away!*

   - *--valgrind*.
   - *-s/--suite*. Not needed for test suites in the test/ directory anyway.
   - *--no-suppress-dialogs/--suppress-dialogs*. Let's hard-code the
   default value, which is to suppress dialogs on Windows.
   - *--no-store-unexpected-output/--store-unexpected-output*. Let's
   hard-code the default value, which is to store (and display) unexpected
   output.
   - Support for building binaries before running tests on them. That
   obsoletes the flags *--build-only, --no-build, -S, --build-system,
   --snapshot, --simulator, --mips-arch-variant, --noprof*. Going forward,
   the way to build V8 is to use GYP (plus the native toolchain of the
   respective platform). The original test.py with building-with-SCons support
   will stay around for the remaining time until SCons is no longer supported
   at all.
   - *--special-command*. This is both unintuitive to use and cumbersome to
   handle within the script. I'm planning to introduce --command-prefix and
   --extra-flags instead.
   - The ability to run the *sputnik* and *es5conform* test suites. Both
   are replaced by test262.
   - The ability to run the V8 *benchmarks* as a test suite. As far as I'm
   aware, nobody is doing that anyway.


And as a small teaser, planned new and improved features include:

   - automatic running of presubmit tests, and a --no-presubmit flag to
   skip that if undesired
   - support for --download-data for the mozilla test suite (and with that
   for all test suites that require downloading additional data)
   - automatic detection of the number of CPU cores, and according
   selection of the -j parameter (unless specified manually)
   - much shorter initial delay before starting to execute tests
   - distribution of testing work in the local network (think "distcc").
   Details will be announced when the feature is ready; of course it will be
   opt-in.


Thoughts?

Cheers,
Jakob

-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to