llvm dev - Jun 2019 - [CMake] External File Dependencies for Unit Tests

On 25/06/2019 11:24, James Henderson via llvm-dev wrote:
> Hi Alex,
> 
>     Would you recommend that I do what is done in
>     unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a string
>     inside the source file, or use an Inputs directory? Both are not
>     great, as you point out about using an Inputs directory
> 
> 
> I'd be inclined to go with the string in the source file approach. It 
> keeps the whole test localised to one place, making it easier to 
> understand what the test is actually testing.
> 
>     Also, I'm not sure that I can create an object without invoking
>     yaml2obj itself, I can't seem to find a function to do this exposed
>     by libObjectYAML.
> 
> 
> It looks to me like you'd need to move big chunks of code out of the 
> yaml2obj tool into the ObjectYAML library. The Minidump version was 
> added quite recently, and took the approach of doing all the layout in 
> the library, whereas for most other formats, the work is done in the 
> executable layer. I think it would be perfectly reasonable to do this 
> code moving, and would then allow you to use the library in your test 
> setup, similar to how minidump works.
[Disclaimer: I'm the person who added the minidump code.]

I would very much like to see this happen. Lldb has some unit tests 
which need to binary files to operate. The way that's handled right now 
is by shelling out to yaml2obj from inside the unit test (so, not from 
cmake). However, it would be infinitely better if we could just invoke a 
library function to do this conversion for us.

> 
>     If I do need to invoke yaml2obj, would you happen to know how to
>     tell CMake to build yaml2obj first, and also where would I find that
>     executable?
> 
> 
> I'm not a CMake expert by any means, but I think you would need to 
> create a dependency on yaml2obj from the test target, then add a step in 
> the test's CMakeLists.txt to run yaml2obj and generate your inputs.
I'm
> still not convinced that it's the right way to go though.
Running yaml2obj from the unit test like lldb does is probably a bit 
better than doing it from cmake. You can search for ReadYAMLObjectFile 
to see how it's done there. However, I wouldn't really recommend 
emulating that... :)

cheers,
pl

I actually added support to our unit tests for external file
dependencies a year or so ago.  Search for
`add_llvm_unittest_with_input_files` in unittests/*.txt and that will
give you an example usage.

On Tue, Jun 25, 2019 at 2:40 AM Pavel Labath via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On 25/06/2019 11:24, James Henderson via llvm-dev wrote:
> > Hi Alex,
> >
> >     Would you recommend that I do what is done in
> >     unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a string
> >     inside the source file, or use an Inputs directory? Both are not
> >     great, as you point out about using an Inputs directory
> >
> >
> > I'd be inclined to go with the string in the source file approach.
It
> > keeps the whole test localised to one place, making it easier to
> > understand what the test is actually testing.
> >
> >     Also, I'm not sure that I can create an object without
invoking
> >     yaml2obj itself, I can't seem to find a function to do this
exposed
> >     by libObjectYAML.
> >
> >
> > It looks to me like you'd need to move big chunks of code out of
the
> > yaml2obj tool into the ObjectYAML library. The Minidump version was
> > added quite recently, and took the approach of doing all the layout in
> > the library, whereas for most other formats, the work is done in the
> > executable layer. I think it would be perfectly reasonable to do this
> > code moving, and would then allow you to use the library in your test
> > setup, similar to how minidump works.
>
> [Disclaimer: I'm the person who added the minidump code.]
>
> I would very much like to see this happen. Lldb has some unit tests
> which need to binary files to operate. The way that's handled right now
> is by shelling out to yaml2obj from inside the unit test (so, not from
> cmake). However, it would be infinitely better if we could just invoke a
> library function to do this conversion for us.
>
>
> >
> >     If I do need to invoke yaml2obj, would you happen to know how to
> >     tell CMake to build yaml2obj first, and also where would I find
that
> >     executable?
> >
> >
> > I'm not a CMake expert by any means, but I think you would need to
> > create a dependency on yaml2obj from the test target, then add a step
in
> > the test's CMakeLists.txt to run yaml2obj and generate your
inputs. I'm
> > still not convinced that it's the right way to go though.
>
> Running yaml2obj from the unit test like lldb does is probably a bit
> better than doing it from cmake. You can search for ReadYAMLObjectFile
> to see how it's done there. However, I wouldn't really recommend
> emulating that... :)
>
> cheers,
> pl
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

That said, why doesn't a lit test suffice for the OP's case of
creating an object file and doing something with it?

On Tue, Jun 25, 2019 at 11:20 AM Zachary Turner <zturner at roblox.com>
wrote:
>
> I actually added support to our unit tests for external file
> dependencies a year or so ago.  Search for
> `add_llvm_unittest_with_input_files` in unittests/*.txt and that will
> give you an example usage.
>
> On Tue, Jun 25, 2019 at 2:40 AM Pavel Labath via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On 25/06/2019 11:24, James Henderson via llvm-dev wrote:
> > > Hi Alex,
> > >
> > >     Would you recommend that I do what is done in
> > >     unittest/ObjectYAML/MinidumpYAMLTest.cpp which just uses a
string
> > >     inside the source file, or use an Inputs directory? Both are
not
> > >     great, as you point out about using an Inputs directory
> > >
> > >
> > > I'd be inclined to go with the string in the source file
approach. It
> > > keeps the whole test localised to one place, making it easier to
> > > understand what the test is actually testing.
> > >
> > >     Also, I'm not sure that I can create an object without
invoking
> > >     yaml2obj itself, I can't seem to find a function to do
this exposed
> > >     by libObjectYAML.
> > >
> > >
> > > It looks to me like you'd need to move big chunks of code out
of the
> > > yaml2obj tool into the ObjectYAML library. The Minidump version
was
> > > added quite recently, and took the approach of doing all the
layout in
> > > the library, whereas for most other formats, the work is done in
the
> > > executable layer. I think it would be perfectly reasonable to do
this
> > > code moving, and would then allow you to use the library in your
test
> > > setup, similar to how minidump works.
> >
> > [Disclaimer: I'm the person who added the minidump code.]
> >
> > I would very much like to see this happen. Lldb has some unit tests
> > which need to binary files to operate. The way that's handled
right now
> > is by shelling out to yaml2obj from inside the unit test (so, not from
> > cmake). However, it would be infinitely better if we could just invoke
a
> > library function to do this conversion for us.
> >
> >
> > >
> > >     If I do need to invoke yaml2obj, would you happen to know how
to
> > >     tell CMake to build yaml2obj first, and also where would I
find that
> > >     executable?
> > >
> > >
> > > I'm not a CMake expert by any means, but I think you would
need to
> > > create a dependency on yaml2obj from the test target, then add a
step in
> > > the test's CMakeLists.txt to run yaml2obj and generate your
inputs. I'm
> > > still not convinced that it's the right way to go though.
> >
> > Running yaml2obj from the unit test like lldb does is probably a bit
> > better than doing it from cmake. You can search for ReadYAMLObjectFile
> > to see how it's done there. However, I wouldn't really
recommend
> > emulating that... :)
> >
> > cheers,
> > pl
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev