[cfe-dev] cindex.py & cmake builds of clang

[David Röthlisberger]

On 8 May 2012, at 11:11, Manuel Klimek wrote:
> The question is whether we consider that a problem with the build system:
> When you refer to libclang, you usually put the "lib" into the name.
> If you consider the "lib" to be part of the name, and want the
> standard unix pattern -l<name> to work, it liblibclang is actually the
> correct file name for the library.

My understanding is that nobody changed the build system *on purpose* to build "liblibclang". It was an unintended side-effect of a change made for Windows.

There are other libraries I refer to in normal speech with the "lib" prefix: "libc", "libcurl". None of these are stored as "liblibc.so" or "liblibcurl.so" on the filesystem. The only exception I can think of is glib (libglib.so) but I think we'd all agree that is a different case to libclang's (because glib's extra "lib" is at the end, not at the front).

Cheers
Dave.


On 8 May 2012, at 11:11, Manuel Klimek wrote:
> On Mon, May 7, 2012 at 3:06 PM, David Röthlisberger <david at rothlis.net> wrote:
>> On 7 May 2012, at 12:30, Arnaud de Grandmaison wrote:
>>> When building clang using cmake, libclang is actually named
>>> 'liblibclang' to avoid a file collision on Windows.
>>> 
>>> It seems to me the cindex.py should be able to cope with both flavours,
>>> as it can not know for sure how the libclang library was generated.
>>> The attached patch teach cindex.py to attempt to load 'liblibclang' in
>>> case the loading of 'libclang' failed.
>> 
>> I have run into this problem as well: One cannot build libclang on Unix using cmake if one wants to use the libclang python bindings.
>> 
>> I raised bug 12620 where I documented the history of this liblibclang nonsense:
>> http://llvm.org/bugs/show_bug.cgi?id=12620
>> 
>> A quick summary: For the sake of Windows Visual Studio users, where a library (clang.dll) cannot share the same base name as an executable (clang.exe), the cmake build system was changed to build libclang.dll, which in turn caused the Unix builds to produce liblibclang.so instead of libclang.so.
>> 
>> In response to "Why can't we produce libclang.dll on Windows and libclang.so on Unix?", Óscar Fuentes replied "This is not a technical problem. We know how to implement any of the choices under consideration."
>> http://clang-developers.42468.n3.nabble.com/Cannot-run-clang-regression-tests-with-cmake-td2961911.html#d1305831334000-246
>> 
>> So it seems that somebody already knows how to fix this, but no further work was done.
>> 
>> I really want the python bindings to work, so I prefer Arnaud's patch over no solution at all; but it feels so filthy to add code to work around defects in the build system, instead of fixing the build system.
> 
> The question is whether we consider that a problem with the build system:
> When you refer to libclang, you usually put the "lib" into the name.
> If you consider the "lib" to be part of the name, and want the
> standard unix pattern -l<name> to work, it liblibclang is actually the
> correct file name for the library, and the proposed patch is the
> correct solution (and the configure build should probably be fixed,
> too ;)
> 
> If we don't consider the name of the library to be libclang, and you
> want to write -lclang, then we can easily fix the cmake file - the
> right fix in that case would in my opinion be to either change the
> library prefix in general, or just the name of the dll on windows,
> depending on what windows devs find more reasonable.
> 
> Cheers,
> /Manuel