clang parser: can libclang be loaded dynamically?

[Kevin Funk]

On Monday, April 11, 2016 12:24:34 PM CEST René J.V. Bertin wrote:
> On Monday April 11 2016 11:51:03 Kevin Funk wrote:
> >You can do, but note you can only load a library with the same/higher
> >version, otherwise you might run into unresolved symbols when loading
> >library on startup. (I'm sure you know that, yes.)
> 
> Yes, though I'm not sure how that would work out in this case. AFAICS a
> fixed ABI translate into function calls that don't change across versions,
> so the main risk would be things like structures that change size in parts
> that you're not supposed to manhandle directly?

libclang promises complete ABI compatibility.

http://clang.llvm.org/docs/Tooling.html

> >I still don't get what's so hard to just provide a standalone, reusable
> >LLVM + Clang package on MacPorts, though...
> 
> What exactly do you mean with that? There are ports for clang-xy and llvm-xy
> where xy goes from 3.4 to 3.9, but they all install the whole toolchain,
> and the older versions are *huge*.

Awesome, that means the newer versions are *okay*? :)

Yes, I meant exactly that.

> The main argument on OS X is of course that anyone doing C/C++ development
> already has a libclang in the toolchain, because Xcode is just about
> unavoidable. 

... and you told us numerous times using the Xcode library is difficult / 
close to impossible. So why do you lock yourself on a dependency which is out 
of your control? (People may upgrade XCode, Apple may break libclang ABI; 
libclang can "disappear"; whatnot)

> What you're saying sounds like you mean a standalone, reusable
> libclang + whatever might be required to use the library. Given how
> libclang is built I'd say that such a package is likely to exist only with
> distribution mechanisms like Debian's where a single build can lead to
> multiple packages that can be more or less independent.

Right, that would be one solution, just compile libclang, nothing else.

> >It took me 10 minutes to set that up on Windows using Emerge, something
> >which now works globally across all Windows versions.
> 
> Still, wouldn't it be useful if you don't have to "emerge" that (which
> surely takes significantly longer than 10 min.) each time a new clang
> version introduces a libclang that works better behind its fixed ABI? 

So, how often do you do that? Once in a month? 

I've been using LLVM+Clang 3.7 for several months under Windows, didn't have  
to recompile it a single time.

> But
> when users can instead update their clang/llvm installation independently
> from KDevelop, e.g. using official packages from llvm.org ... just as they
> do with their compiler?

TBH, I don't see how that'd be useful, just recompile Clang+LLVM in case you 
need a more recent version.

Maybe I'm misunderstanding the whole idea of Homebrew/MacPorts, but I still 
see that as an initiative to compile latest software from source. Which indeed 
is something just advanced users will do, John Doe (i.e. the vast majority) is 
going to install KDevelop from a DMG (i.e. precompiled binaries). -- (If 
someone is ever going to provide a DMG).

People also understand that compiling an IDE + deps from source "may take a 
little longer"..., so the "extra 10 minutes" does not count.

I'm wondering why you are trying to optimize (the hell out of) a non-common / 
developer work flow. Just compile/install/use Clang+LLVM as every Windows/
Linux developer is doing as well. Be done. 

Regards,
Kevin

> >(Time to revisit policies/workflows in the MacPorts project...?)
> 
> Not going to happen I'm afraid, in part because that would undoubtedly mean
> given up some core features or principles that no one will want to give up.
> Either way, this is not just about MacPorts
> 
> Of course I'm tainted by my annoyance with the way Apple ties the ObjC
> language to the OS rather than to the toolchain, but just forget I
> mentioned that if it seems completely unrelated to you =)
> 
> Cheers,
> René


-- 
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/20160411/2051be70/attachment.sig>