Don’t try to validate trace XML when xmllint not found

[hannes-steffenhagen-diffblue]

This was the intended behaviour to begin with, I just forgot
to put the ‘exit’ there.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[thomasspriggs]

It seems to me that this should exit with an error code, as we haven't tested successfully if xmllint is missing.

[NlightNFotis]

I'm a fan of this idea - even though it looks to me like we have checked if xmllint was found, which is what we care for here, isn't it?

[NlightNFotis]

Also, for something unrelated to this PR, but why is command -v used here instead of whereis? Are there any benefits?

I don't mind it, it was just surprising to me - never seen this before, and for this functionality, I've always seen whereis being used instead.

[hannes-steffenhagen-diffblue]

command is very simple. It just checks if something is on $PATH, optionally returns the path to it and gives me an error code if can’t be found. whereis seems to be a more complicated tool used for actually locating things, which is not what I’m trying to do.

It also doesn’t fail by default if it can’t find anything and gives me ton of different things if it does. For me the question is more the other way round, is there a reason to use whereis when command will do?

[NlightNFotis]

Looks good overall, only would ask if it would be possible to get an error code returned before it gets merged.

[hannes-steffenhagen-diffblue]

@NlightNFotis I'd prefer to keep this consistent with the other cases right now. Having this error out if the prereqs aren't there would be a much bigger change, as it would involve basically changing most of our CI scripts.