clang parser: can libclang be loaded dynamically?

[René J.V. Bertin]

On Monday April 11 2016 14:02:09 Kevin Funk wrote:


>... and you told us numerous times using the Xcode library is difficult / 
>close to impossible. So why do you lock yourself on a dependency which is out 

Not using it, building against it.

>of your control? (People may upgrade XCode, Apple may break libclang ABI; 
>libclang can "disappear"; whatnot)

If libclang promises complete ABI compatibility, upgrading Xcode shouldn't be an issue. That's exactly why I asked about dynamic loading; it allows to update libclang (and/with the rest of the toolchain) without having to update or rebuild KDevelop. Or the opposite, update KDevelop (from a binary package) independently from libclang.

>Right, that would be one solution, just compile libclang, nothing else.

That would probably still require having a full llvm build around? It also only shifts the problem, if indeed libclang does improve "behind" its fixed ABI.

>So, how often do you do that? Once in a month? 

I'd say that's still once month too often. Would you build your own clang/llvm if you could simply grab a binary package?
How often would you adapt the parser so it can load libclang dynamically? ;)

>I've been using LLVM+Clang 3.7 for several months under Windows, didn't have  
>to recompile it a single time.

No, of course not. But how long would an average user (who doesn't work *on* KDevelop or clang) feel inclined to hang on to clang 3.7 rather than upgrade just because it provides the libclang used by KDevelop, and for whatever reason installing a more recent clang version is not an option?
I'm thinking of average users who have an occupation in which they do indeed use KDevelop (and clang), and in which they want to spend their time doing stuff that doesn't involve updating their tools.

Or let's turn the question around. Should packagers and distributions provide KDevelop packages for each of the clang versions users might have installed, if they decide not to ship their own libclang?

>TBH, I don't see how that'd be useful, just recompile Clang+LLVM in case you 
>need a more recent version.

Again, you're approaching this from your experience as a KDevelop developer. Most users do not "just recompile Clang+LLCM" when they want a newer version, they grab a binary package or use an updater.

>Maybe I'm misunderstanding the whole idea of Homebrew/MacPorts, but I still 
>see that as an initiative to compile latest software from source. Which indeed 
>is something just advanced users will do, John Doe (i.e. the vast majority) is 
>going to install KDevelop from a DMG (i.e. precompiled binaries). -- (If 
>someone is ever going to provide a DMG).

You may be right about HomeBrew, but MacPorts is not only for advanced users. It does provide precompiled binaries, but a priori only 1 per port (and OS version). That means that a port for KDevelop will need to impose a clang version for the default configuration which is the only one for which a binary build will be available. If Apple provided a full toolchain the issue wouldn't exist (the default would be to use whatever Xcode-for-your-OS-version provides) but since that's not an option another choice has to be made.

That's the kind of problem for which IMHO no good generic solution exists, except for "the user knows best" (what version s/he wants). Sure, someone who is not satisfied with the default can just build for himself, and with MacPorts that doesn't even mean installing all kinds of -dev packages (it does know build dependencies though). Still a significantly cheaper solution would be much more user-friendly.

Another thing I cannot help but have in the back of my mind : KDevelop isn't the only software that depends on clang (not necessarily libclang). Each of the corresponding packages is going to depend on a specific version. Depending on how well each is maintained, inter-dependency issues, whatever, you might find yourself installing yet another clang+llvm version (for instance because your KDevelop package always depends on the latest stable release). And no matter how cheap disk space is (was, with HDDs O:-)), there's a point where that becomes a waste of space.

>People also understand that compiling an IDE + deps from source "may take a 
>little longer"..., so the "extra 10 minutes" does not count.

What 10 minutes, for doing what?

>I'm wondering why you are trying to optimize (the hell out of) a non-common / 

The idea to dlopen libclang isn't mine, but I do like it.

There may be another approach though that minimises the amount of code to rebuild in order to change the libclang version used. Instead of building and packaging just libclang, why not build/package just kdevclangsupport and libKDevClangPrivate? That ought to be *much* less expensive than building just libclang. Even if you do it after running cmake on a full KDevelop source tree and then a make/make install in the languages/clang subdirectory. That would make the main (big majority) KDevelop chunk would become independent from clang, right?

Barring that, is there an easy way to identify all the functions used from libclang (other than letting the linker print a list of unresolved symbols)? I can always have a look what kind of patch I end up with (undoubtedly using an env. var for declaring the libclang path for starters).

>developer work flow. Just compile/install/use Clang+LLVM as every Windows/
>Linux developer is doing as well. Be done. 

I'd like to see what you are basing that statement on. I strongly doubt that MSWin developers are jumping through the hoops of building clang+llvm from source en masse if they can simply grab a binary installer from llvm.org, run that, and be off doing their actual job. Linux devs and users are a strange bunch who've always seemed inclined to spend almost more time updating their tools (and trying out new distributions) rather than doing actual work with them. But I'd like to hope that's just an impression and that there too, it's only a minority who roll their own for have a good reason.
How many people actually use clang as the main compiler on Linux? I've given up on that, too bad if it's a tad faster.

R.