llvm dev - Jun 2012 - [LLVMdev] [PATCH] cindex.py using find_library

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