could libclang be made a runtime dependency?

[René J.V. Bertin]

On Wednesday November 22 2017 10:57:19 Aleix Pol wrote:

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

True, but we're not talking rocket-science here - and if the library's API and ABI are indeed as frozen as I understand they are there isn't much to maintain anyway. You're looking at a one-time conversion after which you only have to remember to keep following the same approach if ever you start calling "new" libclang functions. Not that it'd be easy to forget that, because once you stop linking to libclang the linker will tell you in no unclear terms when you introduce a hard dependency.
There shouldn't be much risk for undefined and hard-to-debug runtime behaviour either with a frozen ABI. Put the symbol import in a single function (fed from a table), have it check each result and abort on failure (*also* in release builds).

The application of my own I mentioned can still be built both ways (in theory), and in theory at least it shouldn't be hard to implement such a build option for kdev-clang too. I didn't mention that because it does increase complexity a bit.

Seriously, I'm more put off by the need to add UI for finding libclang that works across platforms than by implementing the function-pointer indirection, supposing that all required symbols from libclang can indeed be obtained via a reliable automated script. But I see the benefit of it and I do think they outweigh the implementation cost. (And I'll get an idea of the maintenance cost soon enough because I'll evidently start deploying my own PoC implementation once I have one ;) )

BTW, doesn't Qt have mechanisms in place to make working with with weak links easier, or is that only for Qt components?

R.