clang parser: can libclang be loaded dynamically?
kfunk at kde.org
Tue Apr 12 09:41:01 UTC 2016
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:
> >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
- 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) .
> 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 &
> 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".
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel