[cfe-dev] Clang as a compiler-only tool

[Douglas Gregor]

On Nov 27, 2012, at 7:39 AM, Ted Kremenek <kremenek at apple.com> wrote:

> On Nov 26, 2012, at 9:21 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
>>> The Apple people said that this would happen after the 3.0 release - is anyone planning on making it happen soon?
>> 
>> 
>> I don't know of any plans to work on it.
> 
> My team looked into making the static analyzer a plug-in.  One obstacle we found was that enabling plug-ins increases the start of time of clang.  On the Mac at least, we use export maps to restrict the set of symbols that are exported from the clang executable.  Enabling the plug-ins means we must export far more symbols from the executable, which would have a direct impact on the start up time of clang.  I do not remember the the exact numbers, but this regression in start-up time would be unacceptable.

You're assuming that a plugin architecture implies dynamic linking, but that's not necessarily the case. For example, the JSON Compilation Database uses LLVM's registry mechanism to provide statically-linked, compile-time plugins. What we want is for the static analyzer, ARC migrator, rewriter, etc. to be organized as plugins, that can be enabled (statically), enabled (dynamically as a plugin), or disabled at configure time.

> One possible direction is to create a clang service.  There has been some discussion before of doing this.  A clang service could amortize the cost of starting up over many separate compilations, and possibly provide a better way to enable plug-ins anyway.


Something like a Clang service makes plugins with dynamic linking more valuable. All the more reason to design the plugin architecture to allow switching between static and dynamic at configure time.

	- Doug