could libclang be made a runtime dependency?

[Aleix Pol]

On Wed, Nov 22, 2017 at 10:29 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Wednesday November 22 2017 01:24:39 Kevin Funk wrote:
>
>>For the the fun of it:
>>  ag -G "(\.h|\.cpp)"  -s "clang_\w[\w_]+" plugins/clang -o --no-filename |
>>sort | uniq | wc -l
>
> Fun indeed - but it also shows you have a way to find and list them. Reliably?
>
>>Yes, it would be; but it's *way* too much work to change how we use libclang
>>at this point in time. It's not something we can do with the current manpower
>
> Not to discard your manpower argument, but I did something similar years ago in an application of my own when I discovered that plugins couldn't always access the host app's symbols directly on all platforms. Most of the work was done automatically after I wrote a set of macros that hide the exact way functions are called (basically `#define foo(x) (table->foo_p(x))`) and knowing me I ran the search/replace commands in vi.
> Of course that was in C and there was no one to frown upon my use of macros O:-)
>
>>-- nor does it really buy us much (besides not crashing the IDE in case
>>libclang causes a segfault...).
>
> I'm not even certain about that - dlopen'ing a library isn't any different from having it loaded by the dynamic loader on the platforms I know, in that aspect. You'd have to run a helper process to get clang crash protection, no?
>
> KDevelop devs wouldn't buy much, except those who work directly on kdev-clang because testing it with different libclang versions becomes trivial.
> The real benefit would be to packagers and users of (binary) packages as it becomes possible to install clang and kdevelop packages independently and without to ship a libclang copy with KDevelop. I'm not sure how but it might also make it easier to work around the crash you get when running a Mesa build that depends on an incompatible unversioned libLLVM copy.
>
>>Yes, libclang (the C interface to Clang to make that clear) has a strong API/
>>ABI-compat guarantee across version changes.
>
> And a C API means you don't have to worry about name-mangling.
>
>>I'm not sure what you mean with 'the plugin keeps track of which functions
>>fail to import'. The point of ABI guarantees in the scenario you mentioned is
>>to avoid running into exactly that.
>
> So none of the KDevelop-specific patches or the mentioned new features come with an API/ABI *extension*? If that's guaranteed then indeed there's no need to assume certain imports can fail and others shouldn't.
>
>>You can't really know what version of Clang it was built from, you probably
>>can't legally redistribute it (if wanted)
>
> The point would be that there's no need for that. There are ways to determine at runtime where the library lives.
>
>>and there's no guarantee of ABI
>>compatibility across version changes in this particular binary either (it's
>>out of your control).
>
> You may be right, but I've been told multiple times (by an Apple employe) that Apple don't include all kinds of proprietary code or even build tricks. With them being (having been?) a major actor in LLVM development I don't think they have any reason to.
>
>>Does linking it even work to begin with?
>
> I seem to recall that yes, you can link to it manually. It's been a long time since I tried though.
> Pointing the build process to it is hopeless though.
>
>>Anyhow. I think that discussion is moot. We'll not help advancing KDevelop on
>>macOS by fixing purely hypothetical problems.
>
> This isn't a hypothetical problem for everyone, packagers in particular. That's coming from personal experience with packaging for MacPorts, but I'm pretty certain that wouldn't be much different if I were writing DebUbuntu packaging.
>
> If manpower is the only real bottleneck here at the moment I could provide enough at least for a proof of concept implementation (if that formula above indeed catches everything).

Please note manpower doesn't only mean creating the patch but maintain
it over time.

Anything that is run-time is always more costly than compile-time.

Aleix