[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#264879, @labath wrote:

> In http://reviews.llvm.org/D13625#264862, @tfiala wrote:
>
> > In http://reviews.llvm.org/D13625#264786, @labath wrote:
> >
> > > Could you submit the change with full context next time? It makes review much easier.
> >
> >
> > Tell me the diff line you want.  I'm doing the same type of diffs I have submitted for years.  I'll adjust my process.
>
>
> It depends on your process I guess. If you are generating the diff from svn, the command is `svn diff --diff-cmd "diff -x -U9999"`. If you are using arcanist to upload your diffs (which I recommend, btw :) ), it will do that for you.


I'll check out archaist, thanks.

> > 

> 

> > 

> 

> > > I don't understand what are you trying to achieve completely, but it feels to me you are trying to solve the wrong side of the problem. If we are on a system which uses lib64 as the directory for it's libraries, then lldb libraries should go into the lib64 folder as well (by compiling with -DLLVM_LIBDIR_SUFFIX=64). If the directory still comes out wrong (or the libraries don't end up in lib64) then we should fix that. Could you try if -DLLVM_LIBDIR_SUFFIX=64 solves your problems first?

> 

> > 

> 

> > 

> 

> > Python's choice of desired lib dir is orthogonal to whatever else we want to do on a system.  The most precise way to handle that is to ask python to tell us where it wants its lib/module dirs placed.  If we go to a system where python (for whatever reason, including somebody who builds a custom python that does something else entirely) wants to put it in some entirely different lib configuration, this will handle it.  Going to a fixed directory to satisfy python's module directory, which itself can change based on build configuration, doesn't seem like a good idea.

> 

> > 

> 

> > This change asks python "where do you put your libs" on POSIX systems (Xcode build excluded).  And then lldb learns and responds to it.  I much prefer that to saying the lib directory for all of lldb must match whatever the python happens to be doing.

> 

> > 

> 

> > That's my take.

> 

> 

> Ok. Is this some hypothetical scenario, or have you actually encountered a system where python uses e.g. lib64 and the rest of the system the opposite?


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.

> 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?  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.

> 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?


http://reviews.llvm.org/D13625