[cfe-dev] Clang 3.5 Release Pre-Pre-Pre-Announcement
Alp Toker
alp at nuanti.com
Sun May 18 15:33:24 PDT 2014
On 19/05/2014 00:31, Nico Weber wrote:
> On Sun, May 18, 2014 at 1:34 PM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
>
> 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> <mailto: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>
> <mailto: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>
>
> <mailto: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.
>
>
> I don't have a dog in this race either way, but I should point out
> that if you build with -fvisibility=hidden and let your annotation
> expand to __attribute__((visibility("default"))) while compiling your
> library and to nothing for clients of your library, non-Windows shared
> builds
That implies all LLVM developers would have to maintain a shared build
*precisely* matching whatever DLL layout is chosen for Windows, using
the same feature enable flags and building the same set of LLVM SVN modules.
Even assuming all LLVM developers switch to the shared library build,
anyone working on LLVM core without clang would be left out in the cold
and liable to break the build with every commit. The whole idea relies
on a chain of flaky assumptions and even then it's a pain to maintain.
> will work exactly when the the Windows shared build works. (This is
> how the Chromium components build works, and it works fairly well
> there as far as I can tell.)
Nico, that sounds like confirmation bias. I can say from first hand
experience that the Chromium import/exports don't serve projects outside
of Google because they're hard-coded to match the distribution layout
you guys are using for the Google Chrome product.
Exclude a single module, try to split out a component for Debian/Fedora
packages etc. and the annotations become entirely unusable. This won't
be acceptable for LLVM.
Alp.
>
> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
--
http://www.nuanti.com
the browser experts
More information about the cfe-dev
mailing list