In article <4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE@gmail.com
Bill Wendling <email@example.com
Have you been sleeping poorly worried about the Clang 3.5
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
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
refactoring tool developers and there is an issue with the way the
Windows packages are being built that causes them to omit many
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
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.