<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 12, 2014 at 11:44 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Chandler,<div class=""><div><br><div><div>On Apr 12, 2014, at 7:46 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
We already have separate libraries for some of these components (the disassembler at least is cleanly factored out). Why not refactor the target initialization code, etc., so that tools which don't need the various bits of a particular target can easily just not link that sub-library?</div>
</blockquote><br></div></div></div><div>That approach only makes sense in the context of linking LLVM statically.  We are trying to use LLVM as a dynamic library, and we’re very concerned about minimizing the distribution and storage footprint of that library.</div>
</div></blockquote><div><br></div><div>So, I think I understand that. Is there anything weird or special about the dynamic library, or is it just essentially 'libMyLLVM.so' (or dylib, or whatever) that contains all of the LLVM bits you need?</div>
<div><br></div><div>Assuming its just a big shared library with the LLVM bits (and whatever other bits) you need, you're essentially composing this shared library out of several smaller LLVM archives. I'm suggesting that you vary which smaller archives get linked in between the debug and the release shared library. (more details below)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I also disagree that requiring source changes in the client application to determine whether, say, the assembler printer for a given target is linked in or not is a good idea.</div>
</div></blockquote><div><br></div><div>I'm not trying to suggest source changes in the client code. I think all of the source changes can and should be isolated to common parts of LLVM itself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>It’s very important for us to be able to have client applications log final assembly for during development and debugging, but we don’t want to pay the binary size overhead when we deploy.  Aditya’s patch addresses that need by saying that we’d build our release builds with different build settings than our debug builds, which is already the case in lots of other ways.  What you’re proposing requires the client applications (which are linking against a shared LLVM library) to know when the LLVM library was built for deployment or development.</div>
</div></blockquote><div><br></div><div>Not really. LLVM can always provide stubs that handle the difference between deployment vs. development here.</div><div><br></div><div>You still need some way to control whether the assembly is dumped, etc. I would suggest using one of the *existing* build parameters for that such is NDEBUG, or even commandline flags, which just produce an error if the assembly printing library isn't available in whatever mode it is being built.</div>
<div><br></div><div>The really important thing for me is that we don't end up with yet more permutations of ways to build the actual targets themselves. Instead, I feel like clients of the *target* (which might be some umbrella LLVM library, or the opt tool, or whatever else you have) can be clients of just the core sub-libraries of the target or also of the asm printing in the target. If they use the asm printing, then they have to get linked against the asm printing sub-library. But the target is always built into these smaller sub-libraries and doesn't need to be aware of this parameterization. Is this making sense? Perhaps we are talking past each other if not...</div>
</div></div></div>