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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
