libclang.so vs liblibclang.so wrt cindex.py

cindex.py tries to load libclang.so (on GNU/Linux), and that fails for
me because there isn't one. All I have is liblibclang.so. So what's
going on?

Sounds like a build system bug. Are you building with configure/make or CMake?

  - Doug

Douglas Gregor <dgregor-2kanFRK1NckAvxtiuMwx3w@public.gmane.org> writes:

Douglas Gregor <dgregor@apple.com> writes:

Douglas Gregor <dgregor-2kanFRK1NckAvxtiuMwx3w@public.gmane.org> writes:

bruce.r.stephens@gmail.com writes:

cindex.py tries to load libclang.so (on GNU/Linux), and that fails for
me because there isn't one. All I have is liblibclang.so. So what's
going on?

Sounds like a build system bug. Are you building with configure/make
or CMake?

Looks like a bug in tools/libclang/CMakeLists.txt. All other uses of
add_clang_library list names without the "lib" prefix.

I'm pretty sure that the "lib" prefix was there for avoiding a collision
with the `clang' target used for building the clang executable.

I committed a fix.

Óscar Fuentes <ofv-39ZsbGIQGT7e5aOfsHch1g@public.gmane.org> writes:

bruce.r.stephens-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org writes:

[...]

Looks like a bug in tools/libclang/CMakeLists.txt. All other uses of
add_clang_library list names without the "lib" prefix.

I'm pretty sure that the "lib" prefix was there for avoiding a collision
with the `clang' target used for building the clang executable.

Seems likely. The way to resolve that's not obvious (well, not obvious
to me, anyway) which explains why it was done in that way.

I committed a fix.

Cool, thanks. I can confirm that that fixes it.

Hi Oscar,
Do you happen to know the objectives of this binding? Is the plan to
completely wrap libclang? Will the nosetests eventually replace
c-index-test?

Thanks,
Chad