[Lldb-commits] [PATCH] D13625: Support RHEL 7 and similar systems that use architecture-specific Python lib dirs.

[Todd Fiala via lldb-commits]

tfiala added a comment.

In http://reviews.llvm.org/D13625#264951, @labath wrote:

> > RHEL 7 is already doing this - most of lib is 64-bit.  All of lib64 is 64-bit.  They already use both (~600 MB in lib, ~1GB in lib64 on a stock system).  I have also built custom pythons, and by default python will use lib.  So this is a bad user experience for an lldb developer to have to know that they would have to set their python and their cmake build of lldb to the same lib dir.
>
>
> Ok, thanks for the explanation. I guess we'll have to find some way around it then.
>
> > 
>
> > 
>
> > > I understand your desires, but your approach e.g. makes cross-compiling impossible (or, at least assumes that target python uses the same directory as the build one (if the build machine even has python in the first place)). I'd like to avoid doing this if it is possible to work around it.
>
> > 
>
> > 
>
> > Why would that be the case?
>
>
> You might be cross-compiling from windows-x86 to linux-arm. It's unlikely you will be able to run the target python to ask it something. Unless the distutils thing somehow accesses that info through some magic I am not aware of, in which case I apologise. But ok, I am not that worried about setups like this at the moment.


Okay, I'm totally up for helping if we hit this issue.

> > If the target python for the cross compiler is the one specified in the lldb build (which it would have to be, wouldn't it?), that is the one that will be queried.  i.e. the one getting embedded in the lldb build is the one being asked.  I'd hope that can answer the question correctly.  Also, the approach used here to find the directory is the same one we use to construct the lldb python module in the first place.  So this can't make us any further broken for cross compilation than we already are, and if the cross-compiled python can answer the question correctly, we're all set.

> 

> 

> Yeah, that is probably broken as well, but that's out of scope for this change.

> 

> > > Have you checked whether it is possible to extract this information from cmake, without running any code (perhaps parsing PYTHON_LIBRARIES or something).

> 

> > 

> 

> > 

> 

> > No, I haven't looked at this angle.  I'm asking python the same question we ask it already during the construction of the lldb module packaging.  I'd rather use the same approach that we already use to locate the directory than fabricate another one, precisely because they'll be consistent.

> 

> > 

> 

> > Here's what I'd rather do:

> 

> > 

> 

> > - Keep with this approach since it uses both the same approach we already use (distutils python module) to gather the right location, and the python lib dir is allowed to vary independently of the lib dir used by the rest of the build.  This allows us to get it right with no input from the developer regardless of which python they're using, stock or custom.

> 

> > - If it is proven we are doing something wrong for cross compiling, and somebody wants to make that right, we then change over from using the disutils approach both in generating the partial relative directory for answering 'lldb -P' and in the finalization of python class swig generation step.

> 

> > 

> 

> >   I do think it is a worthwhile cleanup to do at some point to get rid of any direct use of 'lib' in the source to use what cmake provides (through the lib dir macros you mentioned previously).  But I'd see that as a cleanup activity orthogonal to this change.

> 

> > 

> 

> >   Thoughts?

> 

> 

> Ok, let's keep this as is. At some point, someone will have to go in and fix this though.


That sounds totally reasonable.

Thanks, Pavel!

I'll wait for a while to hear if either @emaste or @dawn chime in.


http://reviews.llvm.org/D13625