[cfe-dev] Clang 3.5 Release Pre-Pre-Pre-Announcement

[Alp Toker]

On 16/05/2014 22:36, Reid Kleckner wrote:
> On Fri, May 16, 2014 at 11:49 AM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>
>     On 16/05/2014 21:20, Richard wrote:
>
>         In article <4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE at gmail.com
>         <mailto:4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE at gmail.com>>,
>              Bill Wendling <isanbard at gmail.com
>         <mailto:isanbard at gmail.com>> writes:
>
>             Have you been sleeping poorly worried about the Clang 3.5
>             release? Well,
>             this may help! The plan right now is to start testing in
>             July with August
>             as the target release month. There isn't a schedule yet,
>             of course. But it
>             should be a goodly amount of time for all y'all to prepare
>             for the release
>             process.
>
>             If you have any questions, please let me know. If you'd
>             like to volunteer
>             to be a tester, also let me know. :-)
>
>         I have some packaging changes I'd like to see in place for the 3.5
>         packaging.  The changes include some more utilities in the
>         package for
>         refactoring tool developers and there is an issue with the way the
>         Windows packages are being built that causes them to omit many
>         of the
>         things in the unix packages.  Again, this is to make it easier to
>         write refactoring tools.
>
>
>     So far the idea with the Windows installer has been to provide a
>     toolchain rather than a complete SDK, but it'd be nice to see if
>     we can head in that direction, perhaps with a separate SDK package.
>
>     CC'ing in Hans who has opinions on this.
>
>     Which files did you want to include specifically?
>
>
> Initially I didn't want to do this because it bloats the installation. 
>  The package itself is compressed, so a lot of the code duplication is 
> mitigated.
>
> Normally people solve this with shared libraries, and I assumed that's 
> what we did on Linux, where we have a shared library build.  Turns out 
> I was wrong, our pre-built binaries are totally static.  So maybe this 
> doesn't matter as much as I thought it did.
>
> Relatedly, I think at some point we should add LLVM_EXPORT annotations 
> to APIs in Support/ADT, IR, Target, etc,


I agree that it would be absolutely fantastic to support shared library 
/ dll builds in the configuration you describe and think we should work 
towards that.

I hope however that we _never_ attempt to do it with annotations like 
LLVM_EXPORT in the source core, nor with export lists. The reason:

1) They're a complete pain to maintain for developers not working on 
Windows.

2) Even on Windows, there are at least two possible dynamic linking 
configurations:
   (a) several modular DLLs
   (b) LLVM.dll + clang.dll
   (c) LLVMClang.dll

Annotations could only ever support one of the above given that what's 
exported and what's imported is different for each.

> so that we can reduce our .dynsym count and actually support an 
> LLVM.dll on Windows.

So, it strikes me that this problem has great parallels with LTO, 
specifically the task of calculating the minimal set of symbols and 
interdependencies between modules (in this case shared libraries and 
executables).

Perhaps we can treat this as a technology problem and hook into LTO or 
introduce some similar analysis to calculate shared library import / 
exports without having to pepper them throughout the source code.

Rafael and I were discussing something like in person recently. Rafael, 
can you think of a way the LTO machinery could assist in determining DLL 
imports and exports at build time?

> However, I know there is *strong* resistance in some camps due to the 
> burden this would impose.

That resistance is valid. Annotations have been a total mess in the 
projects I've seen them applied. Apart from LLVM I'm sure other projects 
like WebKit / Chromium wanting to support DLL builds would benefit from 
any solution we come up with.

Alp.


-- 
http://www.nuanti.com
the browser experts