clang parser: can libclang be loaded dynamically?

[René J.V. Bertin]

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

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.

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. 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); 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? 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?

R.