Print number of errors, warnings and duration of compilation for every target.
Search for project to build if project/workspace are not specified

-Rename unit test and error message (Specifying either -project or -workspace is no longer required)
-add description method for Options for easier debugging
Merge pull request #307 from facebook/add_total_compile_time_for_target

Print number of errors, warnings and duration of compilation for every target
Merge pull request #309 from spesholized/master

Search for project to build if project/workspace are not specified
Synchronize standard user defaults after clearing filter testcases key.
Add "error" attribute to testcase element in JUnit reporter if test result is error.
Convert all float values to double values.
Merge pull request #317 from facebook/nekto/convert_float_to_double

Convert all float values to double values.
Merge pull request #315 from facebook/nekto/synchronize_defaults_fix

Synchronize standard user defaults after clearing filter testcases key.
Merge pull request #316 from facebook/nekto/add_error_element_to_junit

Add "error" attribute to testcase element in JUnit reporter
Code cleaning.
Merge pull request #320 from facebook/nekto/code_cleaning

Code cleaning.
Use __CFPREFERENCES_AVOID_DAEMON = YES to fix pref clobbering

From @fpotter:

The problem is that preference values are causing SenTestinkgKit + XCTest to prematurely run tests... when all we wanted to do was query the tests in the bundle.

Here's what happens ...

    otest-query loads the test bundle.
    the test bundle links SenTestingKit, so dyld goes a ahead and loads SenTestingKit.
    SenTestingKit has an initialization function (i.e. marked with __attribute__((constructor))), so dyld runs that.
    The initialization function checks to see if the SenTest preference value is set. If so, it starts running tests immediately. (At this point, we haven't even gotten back to otest-query yet - it's still waiting for the bundle to finish loading).
    As soon as SenTestingKit has finished running the tests, it exits. We never return to otest-query.

So, the idea here was to clear the value of the SenTest preference before loading the test bundle. That should work... but it seems to fail intermittently, and I think I now know why.

You would assume the prefs values are read/written from ~/Library/Preferences/<app name>.plist. You would also think that prefs values are never synchronized until you explicitly call /synchronize/. That's what I thought, anyway.

As it turns out, there's actually a system service called cfprefsd that manages preferences and reading/writing them from the Preferences directory. It also caches preference values. If we're running otest-query processes in parallel, and they're each reading/writing via this daemon... it'd be expected for them to eventually stomp on each other.

But, there seems to be a way to disable the daemon usage, so I think we should do that. If you set __CFPREFERENCES_AVOID_DAEMON=YES in the environment before running otest-query, we'll be guaranteed that it won't read data from cfprefsd. That should give us more deterministic behavior. Also, I bet this makes it so that defaults are only synchronized when we explicitly call synchronize.
Merge pull request #321 from LegNeato/master

Use __CFPREFERENCES_AVOID_DAEMON = YES to fix pref clobbering
Fixed parsing for analyze targets
Merge pull request #327 from donaldkwong/master

Fixed parsing for analyze targets
[TextReporter] Print oc unit errors in the failures section

When oc unit error occurs (unable to read build settings for target, fails to query the list of test cases in the test bundle, test bundle contained no tests) the error details are printed only in the stream but aren't then repeated in the failures section. That results in the simple messages like '** TEST FAILED: N passed, 0 failed, 0 errored, N total **' without summarizing failures.
This commit fixes such situations.
on Xcode 5.1, setting env variables is changed from setenv to export
use DTiPhoneSimulatorRemoteClient instead of iPhoneSimulatorRemoteClient

This is working towards the fix for `iPhoneSimulatorRemoteClient` not
working on iOS 7.1 / Xcode 5.1 DP.

It's going to let us pass a lot more info to the iPhone Simulator,
including device name and architecture.
Make xctool compatible with Xcode 5.1

- Respect `-destination` option when running iOS tests.
- Support running test without `-destination` option specified.
- Validate `-destination` option value before running any actions:
1) check whether device with provided `name` exists,
2) check whether iOS sdk with provided `os` version exists,
3) check whether provided device supports provided sdk (only if both os version and device name are provided).
- Add `-destination-timeout` option support.
- Don't update valid `-sdk` flags

Details:
1) Validation of `-destination` option is done using `SimulatorHost.framework`. This frameworks gives us reference to all available sdks and devices.
2) Moved destination option parsing into `XCToolUtil`.