llvm dev - Aug 2014 - [LLVMdev] Plans for the Apple supported Darwin buildbot cluster

On 14 August 2014 11:13, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> Our Jenkins config just runs llvm-lit manually after building (we use Ninja
not make in Jenkins because it's vastly faster for incremental builds and we
have several LLVM forks / versions that we test).  I agree that having a make /
ninja target for the check would be useful, but the lit option was the minimum
work we needed to get the pretty graphs out of Jenkins (and, more importantly,
the regression emails).
I use ninja, too. And ccache. And shared libs for debug builds. And gold. :)

> Note that Jenkins doesn't have a default location for the XML file
either, so we end up specifying this in the llvm-lit command and in the Jenkins
config.  It might be nice for the check-all-xml (or whatever) target to put it
in a fixed location so people configuring Jenkins just need to tell it where to
look in one place.
Can't it be the output of a verbose build, like the textual version?

--renato

On 14 Aug 2014, at 11:17, Renato Golin <renato.golin at linaro.org> wrote:
> Can't it be the output of a verbose build, like the textual version?
Sure, but where do you put it?  The XML file that you produce is:

- Really, really big
- Not human readable (for most values of 'human')

So you don't want to send it to the standard output.  The things that want
to parse it expect a file in the filesystem.  So if you want the verbose build
to be sticking it in a well-known file then I don't have strong objections,
but it seems to be conflating two things.  We run lit in -q mode in Jenkins,
because we don't want big console logs duplicating the information in the
XML.

David

On 14 August 2014 11:26, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> So you don't want to send it to the standard output.  The things that
want to parse it expect a file in the filesystem.  So if you want the verbose
build to be sticking it in a well-known file then I don't have strong
objections, but it seems to be conflating two things.  We run lit in -q mode in
Jenkins, because we don't want big console logs duplicating the information
in the XML.
I could be wrong, but I thought that buildbots already stored the
standard output into a file for parsing, so Jenkins would possibly do
the same? It seems not.

Since you're requesting an XML output (same as when requesting verbose
textual output), you will get a lot of output, so redirecting stdout
to a file on the integration level seems like the most sensible
solution on the tool level.

cheers,
--renato