Support JSON trace format

[nchaimov]

Support the JSON trace format with a new json argument to the trace field of Measurements. This should collect a trace in TAU trace format, as with the existing slog2 option, but then convert with tau_trace2json instead of tau2slog2 and open in Chrome.

[nchaimov]

This is implemented in PR #324, although merging of that is waiting on fixing an issue with the Travis testing. Testing succeeds locally, but building the tau_trace2json command line tool is failing on Travis for some reason.

[zbeekman]

It looks like we've been having silent build failures for quite some time on Travis-CI: https://travis-ci.org/ParaToolsInc/taucmdr/builds/520004243#L2573

g++   -O2 -g -I/home/travis/taucmdr-test/system/tau/tau-2.28/include -I. -o trace2profile handlers.o readTrace.o trace2profile.o -L/home/travis/taucmdr-test/system/tau/tau-2.28/x86_64/lib -lTAU_traceinput-e1fcdaba
/usr/bin/ld: cannot find -lTAU_traceinput-e1fcdaba
collect2: error: ld returned 1 exit status
make[2]: *** [trace2profile] Error 1
make[2]: Target `all' not remade because of errors.
make[2]: Leaving directory `/home/travis/taucmdr-test/system/tau/tau-2.28/utils/trace2profile'
make[1]: *** [trace2profile/trace2profile] Error 2

It seems that make install is masking the return value, or that taucmdr is not throwing an error when installation fails.

[zbeekman]

Hmmm that goes back a long way... to before SC2017 I guess that's not the source of the error in #324 unless #324 relies on that library.

[nchaimov]

The new error is with tau_trace2json, which is a new tool in TAU. That may be a related error. The difference is that in the chrome_tracing branch, tau_trace2json is included in the list of tools that TAU Commander requires, so the install fails when it fails to be built.

Both tools are supposed to link against $(TAU_TRACE_INPUT_LIB). I am guessing that that library is not getting built with the minimal TAU build.

[zbeekman]

yes I think that's right. It's either not getting built or the build is silently failing somewhere. I was wondering if it was OS specific and wanted to test against more GCCs and OS versions so I expanded the build matrix since 14.04 and gcc 4.8 are getting a bit long in the tooth.