llvm dev - Jan 2019 - Is ist a good idea to use lit and other test tools for non llvm projects?

On 2019-01-24 20:17, David Greene via llvm-dev wrote:
> alexp via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
>> I have a project which uses llvm, but is (at least not yet) a
>> contribution / not in the source tree of llvm.
>> Is it a good idea (e.g. instead of using boost test framework) to use
>> the llvm testsuite related tools in this case?
> 
> That probably depends on the project, but I've long wished LLVM's
> testing tools were available outside of LLVM, packaged up separately so
> they could be more widely used.  They're great tools!
lit is, in fact, packaged separately--it is available on PyPI.
FileCheck isn't; there is a similar tool on PyPI, called OutputCheck,
which I have used extensively for similar jobs (matching compiler IR) 
but
I like it much less than FileCheck.

-- 
whitequark

It would be great if FileCheck could be decoupled from llvm and bundled with
lit. Currently it causes friction for llvm-related projects that use lit for
testing but don't actually require/depend on LLVM.

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
whitequark via llvm-dev
Sent: Thursday, January 24, 2019 23:21
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Is ist a good idea to use lit and other test tools for
non llvm projects?

On 2019-01-24 20:17, David Greene via llvm-dev wrote:
> alexp via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
>> I have a project which uses llvm, but is (at least not yet) a 
>> contribution / not in the source tree of llvm.
>> Is it a good idea (e.g. instead of using boost test framework) to use 
>> the llvm testsuite related tools in this case?
> 
> That probably depends on the project, but I've long wished LLVM's 
> testing tools were available outside of LLVM, packaged up separately 
> so they could be more widely used.  They're great tools!
lit is, in fact, packaged separately--it is available on PyPI.
FileCheck isn't; there is a similar tool on PyPI, called OutputCheck, which
I have used extensively for similar jobs (matching compiler IR) but I like it
much less than FileCheck.

--
whitequark
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=YgdxWMcdqQPlU9EdetI-xI79G7ouw9_Us0dFsZnFQYU&m=99eDbMXYFnxKrQ6Pn_-4HoOPKAvtgUoT2C0N-fBTzRU&s=ziDDAiO2ZYhVonQnoiy-SxQ7MILhEVmzp9WoY-JnXu0&e=

Did i miss something? FileCheck is in llvm-build-Dir/bin/FileCheck and
now sucessfully use FileCheck and llvm-lit for my regression tests.
llvm tools are great :-)


Alex

On Thu, 24 Jan 2019 at 20:21, whitequark via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On 2019-01-24 20:17, David Greene via llvm-dev wrote:
> > alexp via llvm-dev <llvm-dev at lists.llvm.org> writes:
> >
> >> I have a project which uses llvm, but is (at least not yet) a
> >> contribution / not in the source tree of llvm.
> >> Is it a good idea (e.g. instead of using boost test framework) to
use
> >> the llvm testsuite related tools in this case?
> >
> > That probably depends on the project, but I've long wished
LLVM's
> > testing tools were available outside of LLVM, packaged up separately
so
> > they could be more widely used.  They're great tools!
>
> lit is, in fact, packaged separately--it is available on PyPI.
> FileCheck isn't; there is a similar tool on PyPI, called OutputCheck,
> which I have used extensively for similar jobs (matching compiler IR)
> but
> I like it much less than FileCheck.
Ha. I'm actually the author of OutputCheck. I wrote it for the STP
constraint solver a few years ago and I made it because I wanted
something like `FileCheck` but without depending on LLVM. It's very
much a poor man's FileCheck. It only has a small subset of FileCheck's
functionality.

I had no idea people were actually using it.

I don't really work on the project anymore but I'm sure the STP
developers would be more than happy for some to work on it.

Thanks,
Dan.