labath wrote:

> > That said, using a package designed (AIUI) for python versions for parsing 
> > versions of gcc/clang does strike me as somewhat... unusual, even if it 
> > does work, so _**maybe**_ there is case to be made for writing something 
> > custom (I'm not sure if we really need anything more elaborate than 
> > `tuple([int(part) for part in version.split(".")])`)
> 
> Agreed. The first time I took a stab at this, that was the first thing I 
> tried, but I quickly discovered that we had at least one tool (I think it was 
> Python itself?) that contained alphabetical characters (something like 
> `1.2.3rc` or `1.2.3.dev`) and I didn't feel like dealing with all the 
> possible edge cases.

Ah yes, I guess *one* of the versions we are parsing is the version of python 
itself..

> We have other packages the test suite relies on (pexpect, psutil, etc) so it 
> seemed reasonable, but if folks feel strongly about it we can maintain our 
> own "version parsing".

While I don't think we should be adding deps willy-nilly, I don't think this 
one is more problematic than others in that they are all available through 
common package management systems. OTOH, it has two things going against it:
- it's a hard dep breaking the ability to run any test (whereas e.g. pexpect  
would only break pexpect-based tests)
- it should be relatively easy to replace

This does not constitute an endorsement of one direction of the other, I'm just 
thinking out loud.

https://github.com/llvm/llvm-project/pull/93712
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to