On Wed, Mar 18, 2020 at 03:40:47PM +0100, Jeremie Courreges-Anglas wrote:
> I got curious about which problems could result from the current deps
> layout. So here's an attempt to switch all the llvm subpackages to
> python3.
Thanks a lot!
> While here:
> - also byte-compile the .py files in the
On Mon, Mar 16 2020, Jeremie Courreges-Anglas wrote:
[...]
> I took a look some days/weeks ago, sadly I didn't note down
> why the switch wasn't straightforward. Maybe I was just busy with
> something else. Looks like a bunch of python files import __future__ so
> this looks promising.
I got
On Mon, Mar 16 2020, Klemens Nanni wrote:
> On Mon, Mar 16, 2020 at 02:57:16PM +0100, Jeremie Courreges-Anglas wrote:
>> On Sun, Mar 15 2020, Klemens Nanni wrote:
>> > All subpackages ave a RDEP on python, so explicitness for -python is
>> > redundant.
>>
>> -python ships a true python module, I
On Mon, Mar 16, 2020 at 02:57:16PM +0100, Jeremie Courreges-Anglas wrote:
> On Sun, Mar 15 2020, Klemens Nanni wrote:
> > All subpackages ave a RDEP on python, so explicitness for -python is
> > redundant.
>
> -python ships a true python module, IMO it should have an rdep on python
> like other p
On Sun, Mar 15 2020, Klemens Nanni wrote:
> All subpackages ave a RDEP on python, so explicitness for -python is
> redundant.
-python ships a true python module, IMO it should have an rdep on python
like other python modules in the tree. Same goes for -lldb.
-main ships a bunch of python script
All subpackages ave a RDEP on python, so explicitness for -python is
redundant.
More importantly, this uncovers how the devel/gtest RDEP has been
clobbered by it; I cannot yet say what inside LLVM actually requires
gtest(1) at runtime and the dependency was added in 2017 for the 4.0.1
update, but
