clang parser: can libclang be loaded dynamically?

Tue Apr 12 12:17:00 UTC 2016

Hi,

have to chime in here

On Tue, Apr 12, 2016 at 12:44 PM, René J.V. <rjvbertin at gmail.com> wrote:

> On Tuesday April 12 2016 11:41:01 Kevin Funk wrote:
> >build
> >- We'd gain a lot by finally providing a DMG users can install via one
> click.
> >
> >Guess where my focus lies.
>
> Yeah, and now consider this (drifting away from the underlying topic
> again!). How many people do you think will consider using KDevelop if it's
> not for some kind of better convenience developing KDE and/or Qt
> applications ... knowing that pure Qt development is already handled quite
> well by Qt Creator (which also provides the only alternative LLDB GUI)?
>

I've been using KDevelop for plain Qt development in the past and I'd
possibly go back to it (from QtCreator) if it was easier to install across
the platforms I work on. I just can't afford to use two different IDE's
depending on the platform. Back then KDevelop still have features that QtC
did not and still does not, along with the fact that I like the way the UI
works better. So yes, I expect people to choose something other than QtC
even for pure Qt-based development, just as people right now are using
other IDE's to do pure Qt-based development (this ranges from vim with
loads of plugins to people using Eclipse or Jetbrains based IDE's to people
using only VS or XCode).

> I'd expect that a big part of the KDevelop audience would be people who
> are looking for an IDE that's better suited for building and adapting
> cross-platform software than Xcode is, and who use that software in their
> actual work. I.e. the kind of user I used to be, who came (back) to the Mac
> because it offered the best compromise between a Unix workstation and a
> desktop PC (Apple used to have a very strong presence in academia and HPC
> before they started targeting "hobos"). Users for whom it's most important
> that their tools "just work", and if possible the same way across all the
> different platforms they're likely to use.
>

> It's one thing to provide a standalone app bundle on a DMG for a text
> editor like Kate, a photo editor like Krita or even a multi-purpose viewer
> like Okular.
> 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
sense to me since it couples the tool you work with to what you're working
on. So if you break something in the shared dependencies you also break the
tool that allows you to fix things again. Thats a bad idea.

> If not I wouldn't be surprised if people who want/need to use KF5
> frameworks turn first to one of the big three "distributions" to get up and
> running -- they'd more than likely do so anyway for the dependencies. Would
> you yourself not use as much as possible from that same source?
> (FYI: for all I know Qt's official distribution packages are still built
> using MacPorts as a source of dependencies)
>

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),
besides the fact that this will possibly duplicate some stuff.

> >> convincing anyone. I may pursue it myself and if that leads to something
> >> potentially useful I'll contribute.
> >
> >Thanks, that's a good start.
>
> It *would* help if I had some pointers for identifying the libclang
> functions that I'd have to load dynamically

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
doing the dynamic resolving and calling of libclang symbols. The
boilerplate code for this function can likely be generated with a bit of
scripting from the output of otool/nm of the kdevelop plugin (as that'll
list all the symbols being used already, just need to filter out which one
of those are defined in libclang and which ones are defined elsewhere).
That limits the number of changes to the original codebase, reducing the
risk of breakages, possibly needing just an initialization call to the
proxy library to tell it where libclang is to be found.

> I know that what I'm proposing here isn't necessary for Linux packaging
> systems that can create multiple packages off a single build. But I guess
> that even on Linux not all distribution systems have that feature. Any
> distribution system that doesn't and that provides more than 1 clang
> version is going to benefit from an easy way to build and package only
> kdev-clang against each of those versions.
>

I don't think the last part is true. Distributions will only build
kdev-clang once against some libclang version, which will likely be
whatever the default clang version is in the distribution at that point.
Now there are two ways this can work: a) different versions of libclang are
not co-installable, they conflict with one another, because they install
the same /usr/lib/libclang.so or b) different versions are co-installable
because they install differently named libraries /usr/lib/libclang-3.x.so.

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
3.6. As long as the to-be-installed 3.8 version of libclang is compatible
it'll provide the same shared library filename that kdevelop needs. This is
also why the versions of libclang would conflict with one another.

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
fine too, happens all the time on linux actually. The downside of this
being that he won't benefit from any bugfixes/features in newer clang
versions while using KDevelop.

It seems at least in Debian b) is the case, the libclang packages are
carrying the version in the package name and install libclang-3.x.so. Using
dlopen would actually not provide any benefit in this case - it actually
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
obvious easy solution to that is to setup a define during compile time with
the name of the libclang library to be used, but then the package again
will depend on a specific libclang version as other libclang versions
install differently-named library files. So you'd end up with an 'search
through all library directories for something starting with libclang and
ending in so.1' and having to make sure to replicate the dynamic linker
lookup logics correctly.

I don't know enough about library loading and dylibs vs. frameworks to
really know how this would work on OSX or wether you'd end up with pretty
much the same issues. However for linux, I think dlopen is not helping in
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
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).

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160412/ae6566fa/attachment.html>