[PATCH] D19333: Move coverage related code into a separate library

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 26 15:06:06 PDT 2016


On Tue, Apr 26, 2016 at 11:14 AM, Justin Bogner <mail at justinbogner.com>
wrote:

> Easwaran Raman <eraman at google.com> writes:
> > Justin, independent of the fact that this is really not a blocker for
> > the profile summary change (as you point out in another thread), this
> > seems like a desirable change to separate coverage from the rest of
> > the ProfileData. Does that make sense?
>
> I'm not really convinced that this is a desirable change, personally. It
> seems like useless busywork to separate these two things, and if we are
> going to make the claim that Coverage is independent/just a user of
> ProfileData, why would it be nested inside the ProfileData subdirectory?
>

I am fine moving Coverage directory out too. However subdir approach is
also used in, for instance, CodeGen/SelectionDAG, so it is not
 unprecedented.  We can model this also like BitCode. For instance, under
ProfileData dir, create two subdirs: Core and Coverage -- but I find that
more work than needed.


>
> I won't block you from doing this, as having more smaller libraries
> doesn't really hurt anything much and I guess it does solve your
> immediate problem, but I do consider this just a hack to work around
> whatever problems the current layout is causing you guys.
>

Making ProfileData more independent can help us longer term -- so let's go
ahead and commit this change.  Having said that,  Easwaran will also work
independently to improve our internal build structure so that similar
issues may not be triggered again elsewhere in the future.

thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160426/5cd6c84b/attachment-0001.html>


More information about the llvm-commits mailing list