clang parser: can libclang be loaded dynamically?

René J.V. Bertin rjvbertin at
Tue Apr 12 10:44:39 UTC 2016

On Tuesday April 12 2016 11:41:01 Kevin Funk wrote:

>Let's face it:
>- We won't increase our audience a lot by improving build times for MacPorts 

Again, this is not only about MacPorts, and please don't think the audience on OS X is directly comparable to the one on Linux or MS Windows.
Above all, don't think that the typical Mac user/developer is as dead-set on doing anything by the book (latest edition) as some KDE devs now targeting OS X appear to be. 

>- 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'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?
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)

>> 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.

>That works. Keep in mind kdev-clang was in a separate repository before and 
>could be built separately.

Yes, I know, but that was before. Once something gets pulled into a larger tree dependencies can start creeping in, but I guess I'll see soon enough. Knowing there shouldn't be any is good enough to start fiddling around.

>We merged kdev-clang for a reason, a decision you are just trying to work-
>around again. I don't see a benefit in factoring out kdev-clang into a 
>separate package, if the kdevelop package still has a runtime dependency on 
>kdev-clang. You're just deferring the requirement "KDevelop needs libclang".

Yes, I'm deferring it, but I'm not proposing to split kdev-clang back off into a separate package. I thought about mentioning that but didn't. The KDevelop source tree isn't large enough to warrant a separation.

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 should be able to whip up a patch for the 2 concerned cmake files later today.


More information about the KDevelop-devel mailing list