Hello all, Is there a reason why the library location code in cindex py does not use find_library() to locate libclang, like in the attached patch? Without it there were problems locating a versioned libclang.so.1 file on Debian, for example. Cheers, Mihai -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120624/3f1774fe/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: cindex.py.patch Type: application/octet-stream Size: 1037 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120624/3f1774fe/attachment.obj>
On 06/25/2012 12:50 AM, Mihai Basa wrote:> Hello all, > > Is there a reason why the library location code in cindex py does not > use find_library() to locate libclang, like in the attached patch? > > Without it there were problems locating a versioned libclang.so.1 file > on Debian, for example.Hi Mihai, as this is a clang related question, I move your mail to the clang mailing list. To your patch:> --- cindex_o.py 2012-06-24 23:31:20.000000000 +0100 > +++ cindex.py 2012-06-24 23:31:05.000000000 +0100 > @@ -65,19 +65,11 @@ > from ctypes import * > import collections > > def get_cindex_library(): > - # FIXME: It's probably not the case that the library is actually found in > - # this location. We need a better system of identifying and loading the > - # CIndex library. It could be on path or elsewhere, or versioned, etc.I don't think the patch solves this fixme entirely. Especially if the library is not on the path, your patch does not provide any solution. (That's why clang_complete has a slightly different version of this function to allow the user to provide a user defined search path)> - import platform > - name = platform.system() > - if name == 'Darwin': > - return cdll.LoadLibrary('libclang.dylib') > - elif name == 'Windows': > - return cdll.LoadLibrary('libclang.dll') > - else: > - return cdll.LoadLibrary('libclang.so') > + from ctypes.util import find_library > + path = find_library('clang') > + return cdll.LoadLibrary(path)Also, I am surprised loading libclang.so fails for you. At least on my system I always get a link from libclang.so to libclang.so.3.1 One solution I can see may be related to a recent patch submission titled "[clang.py] Refactor how ctypes functions are registered" [1] that also reworks the library interface. What I envision is that we have a function in clang.py that clang.py does not load libclang.so when it is initialized, but only when the library would be used the first time. This would allow us to add a function, init_libclang(libpath) that could be called by a plugin and that could provide a user defined path. In case no user defined path was provided, we would look in the system standard locations. Any ideas if this may work? Another possible solution is to require some kind of ClangContext for all object instantiations. Cheers Tobi [1] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120618/059551.html
On 06/25/2012 09:34 AM, Tobias Grosser wrote:> On 06/25/2012 12:50 AM, Mihai Basa wrote: >> Hello all, >> >> Is there a reason why the library location code in cindex py does not >> use find_library() to locate libclang, like in the attached patch? >> >> Without it there were problems locating a versioned libclang.so.1 file >> on Debian, for example. > > Hi Mihai, > > as this is a clang related question, I move your mail to the clang > mailing list. To your patch:And now I even set the reply-to correctly. ;-)> >> --- cindex_o.py 2012-06-24 23:31:20.000000000 +0100 >> +++ cindex.py 2012-06-24 23:31:05.000000000 +0100 >> @@ -65,19 +65,11 @@ >> from ctypes import * >> import collections >> >> def get_cindex_library(): >> - # FIXME: It's probably not the case that the library is actually >> found in >> - # this location. We need a better system of identifying and loading the >> - # CIndex library. It could be on path or elsewhere, or versioned, etc. > > I don't think the patch solves this fixme entirely. Especially if the > library is not on the path, your patch does not provide any solution. > > (That's why clang_complete has a slightly different version of this > function to allow the user to provide a user defined search path) > >> - import platform >> - name = platform.system() >> - if name == 'Darwin': >> - return cdll.LoadLibrary('libclang.dylib') >> - elif name == 'Windows': >> - return cdll.LoadLibrary('libclang.dll') >> - else: >> - return cdll.LoadLibrary('libclang.so') >> + from ctypes.util import find_library >> + path = find_library('clang') >> + return cdll.LoadLibrary(path) > > Also, I am surprised loading libclang.so fails for you. At least on my > system I always get a link from libclang.so to libclang.so.3.1 > > One solution I can see may be related to a recent patch submission > titled "[clang.py] Refactor how ctypes functions are registered" [1] > that also reworks the library interface. > > What I envision is that we have a function in clang.py that clang.py > does not load libclang.so when it is initialized, but only when the > library would be used the first time. This would allow us to add a > function, init_libclang(libpath) that could be called by a plugin and > that could provide a user defined path. In case no user defined path > was provided, we would look in the system standard locations. > > Any ideas if this may work? Another possible solution is to require some > kind of ClangContext for all object instantiations. > > Cheers > Tobi > > [1] > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120618/059551.html > > > >