clang parser: can libclang be loaded dynamically?

[René J.V. Bertin]

On Monday April 11 2016 11:51:03 Kevin Funk wrote:

>You can do, but note you can only load a library with the same/higher version, 
>otherwise you might run into unresolved symbols when loading library on 
>startup. (I'm sure you know that, yes.)

Yes, though I'm not sure how that would work out in this case. AFAICS a fixed ABI translate into function calls that don't change across versions, so the main risk would be things like structures that change size in parts that you're not supposed to manhandle directly?

>I still don't get what's so hard to just provide a standalone, reusable LLVM + 
>Clang package on MacPorts, though...

What exactly do you mean with that? There are ports for clang-xy and llvm-xy where xy goes from 3.4 to 3.9, but they all install the whole toolchain, and the older versions are *huge*. 

The main argument on OS X is of course that anyone doing C/C++ development already has a libclang in the toolchain, because Xcode is just about unavoidable. What you're saying sounds like you mean a standalone, reusable libclang + whatever might be required to use the library. Given how libclang is built I'd say that such a package is likely to exist only with distribution mechanisms like Debian's where a single build can lead to multiple packages that can be more or less independent.

>It took me 10 minutes to set that up on Windows using Emerge, something which 
>now works globally across all Windows versions.

Still, wouldn't it be useful if you don't have to "emerge" that (which surely takes significantly longer than 10 min.) each time a new clang version introduces a libclang that works better behind its fixed ABI? But when users can instead update their clang/llvm installation independently from KDevelop, e.g. using official packages from llvm.org ... just as they do with their compiler?

>
>(Time to revisit policies/workflows in the MacPorts project...?)

Not going to happen I'm afraid, in part because that would undoubtedly mean given up some core features or principles that no one will want to give up. Either way, this is not just about MacPorts

Of course I'm tainted by my annoyance with the way Apple ties the ObjC language to the OS rather than to the toolchain, but just forget I mentioned that if it seems completely unrelated to you =)

Cheers,
René