[lldb-dev] lldb inline tests and Makefiles

Zachary Turner zturner at google.com
Mon Dec 15 10:56:30 PST 2014


I put up a patch to lldb-commits.  It's pretty trivial, but please take a
look anyway.

On Mon Dec 15 2014 at 10:41:06 AM Sean Callanan <scallanan at apple.com> wrote:

> I like your idea: have Python generate a Makefile if one is not present
> and not delete the Makefile after the run.  We just have to remember not to
> check inline test cases’ Makefiles into the repository.
>
> This way you can have your own Makefiles to build things – and in fact
> Python will happily leave those Makefiles for you to reproduce test results
> – but adding a new “inline” testcase is still as simple as possible.
>
> Sean
>
> > On Dec 15, 2014, at 9:33 AM, Greg Clayton <gclayton at apple.com> wrote:
> >
> > I would like to see "Makefile" files for each test and avoid the "python
> will magically do this for me" stuff. I had an inline test that was failing
> and wanted to test what it was doing to figure out what was wrong and I
> added a Makefile to the directory.
> >
> > I vote to make each directory contain a makefile so we can CD into and
> just type "make". Most inline tests might be simple, but it would be nice
> to easily be able to build them.
> >
> > The right fix for this is to fix the inline test code to check for a
> Makefile first and if one doesn't exist, create one, else leave the
> existing one there.
> >
> > Greg
> >
> >> On Dec 12, 2014, at 6:19 PM, Zachary Turner <zturner at google.com> wrote:
> >>
> >> Agreed, but that's a difficult problem to solve given the current
> architecture of the test suite. In my ideal world, we would just build all
> the test executables at the same time we build lldb, and that would even
> speed up the test suite, but i think we're a ways away from that.
> >> On Fri, Dec 12, 2014 at 5:50 PM Jonathan Roelofs <
> jonathan at codesourcery.com> wrote:
> >>
> >>
> >> On 12/12/14 4:35 PM, Zachary Turner wrote:
> >>> lldb inline tests seem to generate their own Makefile and then clean
> it up
> >>> after they're done.  lldb\test\lang\objc\objc-runtime-ivars seems to
> have a
> >>> Makefile checked into the repo.  So when I run the test suite, it
> deletes
> >>> this repo and creates an annoyance every time I go to commit a
> changelist
> >>> I'm working on, because I have to remember to undo the fact that this
> file
> >>> is about to get deleted from the repo.
> >>>
> >>> What's the correct thing to do here?  Should we: a) Remove this
> Makefile
> >>> from the repo and rely on the inline test to generate it, b) Only do
> >>> something in CleanMakefile() if BuildMakefile() was previously called?
> >>>  (this isn't the case for me locally, since all of these tests are
> disabled
> >>> on Windows, but the cleanup isn't behind a similar check), c) some
> >>> combinatino of the above?
> >> It would be extremely nice if building & testing didn't modify or
> create any
> >> files in the directory checked out from svn/git.  Having that makes it
> a bit
> >> easier to provide build reproducibility guarantees on shipped
> toolchains.
> >>
> >>
> >> Cheers,
> >>
> >> Jon
> >>>
> >>> Would appreciate some assistance, as this is very annoying to keep
> having
> >>> the test suite modify my in-progress CLs.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> lldb-dev mailing list
> >>> lldb-dev at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>>
> >>
> >> --
> >> Jon Roelofs
> >> jonathan at codesourcery.com
> >> CodeSourcery / Mentor Embedded
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141215/eaa3b416/attachment.html>


More information about the lldb-dev mailing list