clang parser: can libclang be loaded dynamically?

[Kevin Funk]

On Tuesday, April 12, 2016 10:50:43 AM CEST René J.V. Bertin wrote:
> On Monday April 11 2016 20:38:05 Milian Wolff wrote:
> 
> Hi,
> 
> >I don't get it.
> 
> And I don't get that people don't get my point - have I been too verbose in
> trying to make it.
> >You link against libclang.so.X and be done with it. If the ABI
> >changes, you get a runtime link error. If the ABI is stable, and a fitting
> >lib can be found everything works. Why do you need to dlopen?
> 
> Of course that works, and that's fine for people who build everything
> themselves, or for people who use whatever their distribution offers them.
> 
> Again, compare with audacity. Why does it have an option to build a version
> that doesn't have a hard, link-time dependency on a set of ffmpeg
> libraries, despite the fact that ffmpeg has a habit of breaking ABI?
> 
> Having a weaker dependency on some external library that 1) isn't a common
> system library 2) isn't cheap to build and 3) already exists in at least 3
> compatible versions can IMHO only be an advantage as soon as you get up out
> of the design-oriented developer's chair and start thinking about getting
> your product to as wide an audience as possible. Including those on
> platforms where you cannot simply do the equivalent of `sudo apt-get
> install libclang-x.y` (or let a kdevelop package depend on a given libclang
> package that pulls in the minimal requirements).

FWIW, I'm thinking about getting KDevelop to a wider audience on OS X. 

Let's face it:
- We won't increase our audience a lot by improving build times for MacPorts 
build
- We'd gain a lot by finally providing a DMG users can install via one click.

Guess where my focus lies.

> Anyway, I'm not going to continue defending this idea against any hope of
> convincing anyone. I may pursue it myself and if that leads to something
> potentially useful I'll contribute.

Thanks, that's a good start.

> Meanwhile, how about my later idea? I now have confirmation that the clang
> dependency is limited to the code in languages/clang, that that directory
> can be built (almost) standalone and that it can be excluded from the
> overall kdevelop build. 

It is standalone, yes. It's a separate plugin.

> That has allowed me to create a dedicated port for
> the kdevelop-clang-parser, which depends on a clang version of choice and
> is a runtime dependency for kdevelop (cf.
> https://github.com/RJVB/macstrop/blob/master/kf5/kdevelop5/Portfile) .

Oh well...

> kdevelop-clang-parser builds up to about 7x faster than the rest of kdevelop
> (or upto almost 9x compared to all of kdevelop); 

If build times are your only concern, you might want to give ccache a try...

> I build it by doing a
> regular cmake step and then make followed by make install inside
> kdevelop/build/languages/clang . Building kdevelop without the plugin means
> patching the CMake file in languages.
> 
> It would of course be nicer if the build system supported this directly, for
> instance via a set of options that default to ON (KDEVELOP_BUILD_IDE &
> KDEVELOP_BUILD_CLANG_PARSER).
> 
> Would that go down any easier? If so, am I right that the code in
> languages/clang doesn't depend on anything from outside that directory?

Other way around: nothing depends on languages/clang, yes.

> IOW, should I be able to use KDEVELOP_BUILD_IDE as a filter to in/exclude
> all directories except for languages/clang, or should I expect pitfalls
> doing that?

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

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

Kevin

> R.
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel


-- 
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/defe72fd/attachment.sig>