<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 16, 2014 at 11:49 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On 16/05/2014 21:20, Richard wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In article <<a href="mailto:4FBFE344-19A4-4A9A-9C93-AB9A4554D6CE@gmail.com" target="_blank">4FBFE344-19A4-4A9A-9C93-<u></u>AB9A4554D6CE@gmail.com</a>>,<br>
     Bill Wendling <<a href="mailto:isanbard@gmail.com" target="_blank">isanbard@gmail.com</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you been sleeping poorly worried about the Clang 3.5 release? Well,<br>
this may help! The plan right now is to start testing in July with August<br>
as the target release month. There isn't a schedule yet, of course. But it<br>
should be a goodly amount of time for all y'all to prepare for the release<br>
process.<br>
<br>
If you have any questions, please let me know. If you'd like to volunteer<br>
to be a tester, also let me know. :-)<br>
</blockquote>
I have some packaging changes I'd like to see in place for the 3.5<br>
packaging.  The changes include some more utilities in the package for<br>
refactoring tool developers and there is an issue with the way the<br>
Windows packages are being built that causes them to omit many of the<br>
things in the unix packages.  Again, this is to make it easier to<br>
write refactoring tools.<br>
</blockquote>
<br></div>
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.<br>
<br>
CC'ing in Hans who has opinions on this.<br>
<br>
Which files did you want to include specifically?</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Relatedly, I think at some point we should add LLVM_EXPORT annotations to APIs in Support/ADT, IR, Target, etc, so that we can reduce our .dynsym count and actually support an LLVM.dll on Windows.  However, I know there is *strong* resistance in some camps due to the burden this would impose.</div>
</div></div></div>