clang parser: can libclang be loaded dynamically?

Tue Apr 12 12:23:33 UTC 2016

On Tuesday, April 12, 2016 12:44:39 PM CEST René J.V. Bertin wrote:
> 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.
> >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'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? 

No, traditionally "KDevelop" has just been the IDE, without SDK, without 
compilers. It's just an IDE developed under the KDE umbrella, but I don't 
think we necessarily need to ship an SDK along-side with KDevelop.

We could provide the "KF5/KDE SDK" separately, if needed, but I'm not even 
thinking this far. I'd first like to get our foot into OS X, let people play 
around with KDevelop, potentially attracting new contributors who can actually 
grow the KDevelop on OS X experience.

Providing a full-fledged SDK for developing KF5-based apps is a whole 
different beast. And quite frankly, let's just do one step after the other.

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

Kevin

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

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160412/89d62f5c/attachment-0001.sig>