[PATCH] Added basic testing support for llvm-cov.

[Justin Bogner]

Yuchen Wu <yuchenericwu at hotmail.com> writes:
>> I think this only works correctly if the working dir is specified on the
>> command line with a trailing slash. What if this is called with a
>> spelling like "-C /some/dir"?
>
> I appended an extra "/" to WorkingDir if it's non-empty, should fix
> that issue.

I don't know if that will work on windows or not.

>> Does this behave strangely if InputGCDA or InputGCNO are absolute paths?
>
> It depends, without WorkingDir defined, it should be fine. If
> WorkingDir is defined, then you really shouldn't be using absolute
> paths for InputGCNO and InputGCDA.

Hmm. I guess we should try to error out in that case instead of doing
something strange then.

Overall, I still the semantics of this flag fairly awkward. There's an
implicit requirement that everything is in the same directory, but
there's nothing about the API/invocation that makes this obvious.
Furthermore, without the "-C" flag, we seem to allow the input GCDA and
GCNO to be absolutely anywhere, but our output depends on where,
specifically, they are.

I think we need to step back and think about what we're trying to
accomplish:

1) We want llvm-cov's output to be compatible with gcov.
2) We want the flexibility to specify GCDA and GCNO files at arbitrary
   paths.
3) We want to be able to run the tool with a particular current
   directory.

Now, (3) is a bit vague. What exactly are we trying to accomplish? It's
something like "Run llvm-cov as if we were in some particular directory
and we'd specified GCDA and GCNO files as relative paths from there", or
"Ensure that filenames in our output are relative paths / just the base
name".

I think we need a better understanding of where (3) comes from and what
we're actually gaining from it to continue. Can you clarify?