Error/Warning output formats inconsistent

[dmeehan1968]

I've been using GSL in Xcode as a custom build step, but the output produced by the GSL command is inconsistent and hard to parse into something that Xcode likes as an error message. I've got the following build rule at the moment

errors=`/usr/local/bin/gsl -q -script:${INPUT_FILE_DIR}/specs.gsl -a ${INPUT_FILE_PATH} ${SCRIPT_OUTPUT_FILE_0} 2>&1 | sed -E -n 's#[0-9]+/[0-9]+/[0-9]+[ ][0-9]+:[0-9]+:[0-9]+:[ ]\(*([^g][^s][^l].*)[ ]+([0-9]+):*\)*(.*)#'${INPUT_FILE_DIR}'/\1:\2: \3#p'`
if [ "$errors" ]; then
    echo "$errors"
    exit 1
fi

This matches up the lines starting with date/time, extracts the filename, line number and error message and formats it suitable for Xcode to understand as a build error. You also need to return a non-zero exit code on failure for Xcode to be happy.

With this, you get errors in the Xcode build navigator as you would for regular source code, although XML errors currently won't jump to the source file/line when clicked as the path gets repeated.

<file>:<line>: <message>

As currently implemented, GSL is unhelpful, as formatting of errors in GSL and XML sources are different (braces in one, not the other, around the filename and line number) and the message is split across multiple lines.

Whilst I'm not asking for Xcode compatible output, it would at least be nice if the GSL output was consistent for different failure types. The source just appears to be using a coprintf routine rather than a dedicated logging function to help here.

If anyone can suggest a preferred output style (or if the existing one cannot be deprecated), I may well consider creating a pull request for a suitable implementation.

[hintjens]

Why not make the changes and make a pull request?
On May 10, 2014 5:05 PM, "Dave Meehan" [email protected] wrote:

I've been using GSL in Xcode as a custom build step, but the output
produced by the GSL command is inconsistent and hard to parse into
something that Xcode likes as an error message. I've got the following
build rule at the moment

errors=/usr/local/bin/gsl -q -script:${INPUT_FILE_DIR}/specs.gsl -a ${INPUT_FILE_PATH} ${SCRIPT_OUTPUT_FILE_0} 2>&1 | sed -E -n 's#[0-9]+/[0-9]+/[0-9]+[ ][0-9]+:[0-9]+:[0-9]+:[ ]\(*([^g][^s][^l].*)[ ]+([0-9]+):*\)*(.*)#'${INPUT_FILE_DIR}'/\1:\2: \3#p'
if [ "$errors" ]; then
echo "$errors"
exit 1
fi

This matches up the lines starting with date/time, extracts the filename,
line number and error message and formats it suitable for Xcode to
understand as a build error. You also need to return a non-zero exit code
on failure for Xcode to be happy.

With this, you get errors in the Xcode build navigator as you would for
regular source code, although XML errors currently won't jump to the source
file/line when clicked as the path gets repeated.

::

As currently implemented, GSL is unhelpful, as formatting of errors in GSL
and XML sources are different (braces in one, not the other, around the
filename and line number) and the message is split across multiple lines.

Whilst I'm not asking for Xcode compatible output, it would at least be
nice if the GSL output was consistent for different failure types. The
source just appears to be using a coprintf routine rather than a
dedicated logging function to help here.

If anyone can suggest a preferred output style (or if the existing one
cannot be deprecated), I may well consider creating a pull request for a
suitable implementation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39
.