[Skiboot] [PATCH 2/2] external/gard/tests: Add tests for the gard tool

[Stewart Smith]

Cyril Bur <cyril.bur at au1.ibm.com> writes:
> On Tue, 08 Sep 2015 08:18:12 +1000
> Stewart Smith <stewart at linux.vnet.ibm.com> wrote:
>
>> Cyril Bur <cyril.bur at au1.ibm.com> writes:
>> > Simple tests for the gard tool that can be expanded on over time
>> > +++ b/external/gard/test/Makefile.check
>> 
>> I would have almost expected this as part of the normal gard makefile,
>> but then, again, fitting it into skiboot 'make check' may well be a good
>> idea... although then we have the whole HOSTCC/TARGETCC thing to worry
>> about, and if we were going to have, say, the debian packaging running
>> the test suite as part of build, we'd have to have it get a bit weird to
>> just run the gard test suite.
>> 
>
> Using the 'make check' infrastructure has obvious advantages, at least to me, I
> must admit I didn't really consider disadvantages. Since these are userspace
> components I can't imagine (can't wait to be proven wrong) that HOSTCC/TARGETCC
> will be an issue, they're trivial programs. 

for example, at the moment, with pflash, you can't build skiboot and
then pflash as the makefiles conflict on object names for libflash/
components.

out of tree builds would likely solve all of these problems I
guess... or doing magic make-dist things. Although at the same time,
having a magic single make invocation to make coverity scan through
travis-ci happy is also nice.

In related news, I just spent a bit of the morning fighting with
travis-ci to make coverity scan work automagically (including the
userspace bits)

> You raise an interesting point re having tests run as a part of debian
> packaging... Surely you have thoughts?

Basically that we should do that, something like 'cd external/gard; make
all check" as the build step

>> (At what point should we just go autotools for the userspace components
>> and move them to usr/ rather than external/ ?)
>
> Dibs not! *phew*