clang parser: can libclang be loaded dynamically?

[René J.V. Bertin]

On Tuesday April 12 2016 14:17:00 Andreas Pakulat wrote:

Hi

>depending on the platform. Back then KDevelop still have features that QtC
>did not and still does not,

I'm curious, which features?

>along with the fact that I like the way the UI
>works better.

I can only agree with you there (not even having tabs to show what files are open is a real breaker for me, even if QtC allows you to use separate windows which KDevelop doesn't).
But I just had a look at QtC 4 and I find it much improved (and snappier running against Qt 5.6). Support for cmake-based projects has improved, too.

>> An IDE is a bit different, isn't it? Are you planning to provide the whole
>> KF5 SDK on that DMG, possibly even inside the KDevelop app bundle, XCode
>> style?
>>
>
>I hope thats the goal of Kevin's efforts/plans, anything else makes no

Actually, I hope for him that he doesn't, or that he plans to have infrastructure in place to update that embedded SDK, given the KF5 release rate!

>Yes, they have some things on their build machines from macports to
>generate packages. But the resuling packages do not require anybody to
>install that stuff. They package it (if it is a runtime dependency at all),

I didn't say that (though it did happen with Qt 5.4.0 IIRC). I mentioned this as an implicit hint that MacPorts might be used by a much wider set of users than newcomers to the OS X universe might think.

>Did you consider the option of doing this in a proxy library? That is a
>small library that the plugin would link against (instead of libclang) and
>exports the same ABI as libclang. The actual function implementations then

Yes, I considered that, but ...

>risk of breakages, possibly needing just an initialization call to the
>proxy library to tell it where libclang is to be found.

... if you mean a proxy library that dlopens libclang it's just displacing the problem.
What I had in mind was an approach in which the libclang functions in kdev-clang are replaced with something like this

void (*clang_foo_ptr)(args);
#define clang_foo (*clang_foo_ptr)

bool init_clang_functions()
{
   clang_base = dlopen(libClangPath, flags);
   clang_foo_ptr = dlsym(clang_base, "clang_foo");
}

with a bit of appropriate OOP sauce. I've been doing something similar with a bunch of macros in the plugins of one of my own applications (for functions from the host application), ensuring it can still build without all that dynamic loading, and with all the conditional stuff hidden away.
In other words, plugins are just written as if those proxied functions were available directly, and only contain a table and additional init function (both populated with macros that leave very little room for operator error).

>I don't think the last part is true. Distributions will only build
...
>In case a), a user can simply install the newest version of libclang and
>still use kdevelop because of the binary compatibility that libclang
>provides, hence it does not matter wether kdevelop was built against 3.5 or

The thing is that clang doesn't build like that. As far as I can tell it's been designed from the onset to allow multiple parallel installations.

>The other case means a user can install any number of libclang versions at
>the same time and he's going to get two installed - one for kdevelop and
>one for whatever he needs for his work if the versions are different. Thats

Of course. Now as I said that's fine if the distribution provides a way to install just libclang with its dependencies. It's less acceptable if you need to keep a full clang toolchain around. Just for giggles: the standard clang+llvm 3.7 build from MacPorts' binary package takes a bit over 1Gb. HD space may be cheap nowadays, it's not *that* cheap.

>makes things harder since now C++ code is needed to redo the stuff the
>dynamic linker usually does: finding the libclang-3.x.so to dlopen. The

No, that'd be up to the user to provide! The only thing that'd be needed is some code to pop up the configuration dialog or an error message when the path hasn't been defined yet, or has gone stale.

>any way, maybe I'm overlooking something - do you happen to know why
>audacity uses dlopen for ffmpeg? It seems at least on linux it does not do

To be honest, no. I can only think of 1 important reason: allow the user to use whatever version s/he wants, including local builds with lots of different options (think the "nonfree" configuration). It's also possible that this option was developed for non-Linux platforms where ffmpeg typically isn't provided by the system.

And then there are (potential) licensing issues which probably affect redistribution of the GPL'd FFMpeg binaries. Clang is under the NCSA license from what I understand, and thus hopefully much less affected by that kind of thing.

>so, based on my limited abilities to look at the package: It has a few
>dependencies called libsomething-ffmpeg and it seems to fully link against
>those and not dlopen any of them (at least on Debian).

Audacity can be built both ways, and from what I saw the default Ubuntu (and thus probably Debian) package uses the "static" approach.

Kevin wrote:
> I guess all these misunderstandings / different interpretations of what
> "KDevelop on OS X" should look like are part of the reasons we're repeating
> discussions all over again...

I'm not sure if it's "what should KDevelop look like on OS X" or "what should KDE look like on OS X". I am convinced that ultimately that is something that will have to be decided primarily by (seasoned) Mac users, and not only by newcomers who happen to be the most knowledgeable about KDE.
Let's hope that Andreas is right that KDevelop will also appeal to Qt developers.

But if you really want to get a foot in the door, don't discount MacPorts. Testing is currently underway to publish my KF5 port tree and once that's done it becomes a lot easier to start fine-tuning applications, at least (by default) for a configuration in which shared resources are taken from familiar places like ${prefix}/share, ~/.local/share and ~/.config.
Note that MacPorts does have the possibility to create DMGs which if I understand correctly will contain a bundle for the official installer that installs the payload into the pre-configured prefix. Don't worry, that *is* one of the official ways of installing software on OS X, and all app-bundle applications (= the ones visible in the Finder) will end up in a folder under /Applications.

R.