labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
> 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. > 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. http://reviews.llvm.org/D13625 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
