[lldb-dev] Moving pexpect and unittest2 to lldb/third_party

Thu Oct 22 11:30:29 PDT 2015

(I was eventually going to do this at some point after I verified it was
indeed true).  It should just be called unittest in a stock distribution.

On Thu, Oct 22, 2015 at 11:29 AM, Todd Fiala <todd.fiala at gmail.com> wrote:

> We could also then remove unittest2 from inclusion in the lldb repo.
>
>
> On Thu, Oct 22, 2015 at 11:28 AM, Todd Fiala <todd.fiala at gmail.com> wrote:
>
>> I'd be okay with that.
>>
>> The unittest2 stuff looks like it was a vestige of being incorporated
>> before unittest2 was stock (unitest) on Python 2.[6,7]?.  Everyone should
>> have a unitest included that is effectively what we use as unittest2.
>>
>> -Todd
>>
>> On Thu, Oct 22, 2015 at 10:05 AM, Zachary Turner via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>>> I plan to put this in today.  Greg, should I just go ahead and delete
>>> all the unittest2 stuff entirely?  TBH I'm all for anything that reduces
>>> the complexity of the test suite.  It's got a couple hundred options that
>>> nobody uses, seems like we should start whittling away at stuff that
>>> doesn't get any use.
>>>
>>> If you prefer I leave it in that's less work for me since I have that
>>> patch ready to go, but TBH I'd rather remove it if that's ok.
>>>
>>> On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner <zturner at google.com>
>>> wrote:
>>>
>>>> You can get pretty much the same effect though by just running dotest
>>>> and passing it the folder that the .py file is in.   Then it only runs
>>>> tests in that folder.  You can specify the filename too if you want to
>>>> limit it to one name.  Sure, it's a few keystrokes less to just type
>>>> TestMultithreaded.py or something, but given the extra complexity and the
>>>> fact that it's running a totally different codepath, I wonder if the
>>>> maintenance burden is worth it (I'm guessing no, since apparently it
>>>> doesn't work well enough right now for anyone to use it)
>>>>
>>>> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton <gclayton at apple.com>
>>>> wrote:
>>>>
>>>>> I believe it would import lldb correctly. I don't tend to run the
>>>>> tests individually, but if it did work, I would use it more.
>>>>>
>>>>> > On Oct 22, 2015, at 9:26 AM, Zachary Turner via lldb-dev <
>>>>> lldb-dev at lists.llvm.org> wrote:
>>>>> >
>>>>> > Todd, Greg, can you guys confirm this is true?   The import lldb
>>>>> would succeed if someone had their PYTHONPATH set up just right, but if
>>>>> really none of us care about it, I'm with Tamas in that I'd rather remove
>>>>> it.
>>>>> >
>>>>> > On Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer <
>>>>> tberghammer at google.com> wrote:
>>>>> > Hi Zach,
>>>>> >
>>>>> > I think nobody is using the "if __name__ == '__main__'" block as
>>>>> executing a test file directly isn't working at the moment (the "import
>>>>> lldb" command fails). If you plan to change all test file then I would
>>>>> prefer to remove the reference to unittest2 from them for simplicity if
>>>>> nobody have an objection against it.
>>>>> >
>>>>> > Tamas
>>>>> >
>>>>> > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev <
>>>>> lldb-dev at lists.llvm.org> wrote:
>>>>> > TL;DR - Nobody has to do anything, this is just a heads up that a
>>>>> 400+ file CL is coming.
>>>>> >
>>>>> > IANAL, but I've been told by one that I need to move all third party
>>>>> code used by LLDB to lldb/third_party.  Currently there is only one thing
>>>>> there: the Python `six` module used for creating code that is portable
>>>>> across Python 2 and Python 3.
>>>>> >
>>>>> > The only other 2 instances that I'm aware of are pexpect and
>>>>> unittest2, which are under lldb/test.  I've got some patches locally which
>>>>> move pexpect and unittest2 to lldb/third_party.  I'll hold off on checking
>>>>> them in for a bit to give people a chance to see this message first,
>>>>> because otherwise you might be surprised when you see a CL with 400 files
>>>>> being checked in.
>>>>> >
>>>>> > Nobody will have to do anything after this CL goes in, and
>>>>> everything should continue to work exactly as it currently does.
>>>>> >
>>>>> > The main reason for the churn is that pretty much every single test
>>>>> in LLDB does something like this:
>>>>> >
>>>>> > import unittest2
>>>>> >
>>>>> > ...
>>>>> >
>>>>> > if __name__ == '__main__':
>>>>> >     import atexit
>>>>> >     lldb.SBDebugger.Initialize()
>>>>> >     atexit.register(lambda: lldb.SBDebugger.Terminate())
>>>>> >     unittest2.main()
>>>>> >
>>>>> > This worked when unittest2 was a subfolder of test, but not when
>>>>> it's somewhere else.  Since LLDB's python code is not organized into a
>>>>> standard python package and we treat the scripts like dotest etc as
>>>>> standalone scripts, the way I've made this work is by introducing a module
>>>>> called lldb_shared under test which, when you import it, fixes up sys.path
>>>>> to correctly add all the right locations under lldb/third_party.
>>>>> >
>>>>> > So, every single test now needs a line at the top to import
>>>>> lldb_shared.
>>>>> >
>>>>> > TBH I don't even know if we need this unittest2 stuff anymore (does
>>>>> anyone even use it?)  but even if the answer is no, then that still means
>>>>> changing every file to delete the import statement and the if __name__ ==
>>>>> '__main__': block.
>>>>> >
>>>>> > If there are no major concerns I plan to check this in by the end of
>>>>> the day, or tomorrow.
>>>>> > _______________________________________________
>>>>> > lldb-dev mailing list
>>>>> > lldb-dev at lists.llvm.org
>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>> > _______________________________________________
>>>>> > lldb-dev mailing list
>>>>> > lldb-dev at lists.llvm.org
>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>

-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151022/b57b652a/attachment.html>