llvm dev - Nov 2014 - [LLVMdev] [RFC] New ToolsSupport library for stuff that only tools need

I think for the main goal of cleaning up the Mac-specific hack, a CrashRecovery
library would work equally well. Juergen is more familiar with the WebKit side
of things, so he may be aware of something I’m not thinking of.

Chandler, does splitting out a CrashRecovery library instead seem sane?

Other than code organization and naming, the general idea of splitting out a
CrashRecovery library would be the same as the other patches I sent out. I was
thinking of taking the approach of moving one symbol, fixing everything, then
repeat.

Does that seem like the right approach?

-Chris
> On Nov 6, 2014, at 3:43 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Thu, Nov 6, 2014 at 3:22 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
> The other thought I had which motivated this solution was that if we could
strip all the functionality that is only really used by tools out into a
separate library it would offer cleaner organization of code. Support seems to
often get used as a dumping ground for stuff that just doesn’t fit anywhere
else.
>  
> Based on your feedback and Chandler’s maybe this just isn’t the right
separation. I can look into a solution to address our hackiness without creating
a separate library.
> 
> What other stuff do you think belongs in ToolsSupport that doesn't
belong in Support? Looking back at the initial email, you have command line
parsing and ToolOutputFile.
> 
> We could split out command line parsing, but it doesn't seem worth it,
given that we're still carrying regex support, Unicode conversion, dynamic
library support, and other things that probably aren't absolutely necessary.
> 
> What about splitting out a CrashRecovery library instead? That seems a lot
more targeted and meaningful. We'd probably put ToolOutputFile.cpp in there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/934366e4/attachment.html>

On Thu, Nov 6, 2014 at 6:52 PM, Chris Bieneman <beanz at apple.com> wrote:
> I think for the main goal of cleaning up the Mac-specific hack, a
> CrashRecovery library would work equally well. Juergen is more familiar
> with the WebKit side of things, so he may be aware of something I’m not
> thinking of.
>
> Chandler, does splitting out a CrashRecovery library instead seem sane?
>
I have a preference for leaving it in Support as "dead code" for the
library, and only calling routines to enable that functionality from tools.
This would of course require cleaning up any parts that are inherently bad
when linked into a library.

The reason isn't fundamental, it's just that splitting libraries,
especially as LLVM is currently set up, has a cost. Super fine-grained
libraries don't really make sense in this environment, and 'crash
recovery'
seems quite fine grained and specific. Again, not bad in and of itself, but
not really a good fit in LLVM.


That's my two cents. Naturally, if it isn't *possible* to clean up the
mac-specific hacky bits and factor the crash recovery so that it is only
enabled when called, then that seems like an overriding concern. =]

> Other than code organization and naming, the general idea of splitting out
> a CrashRecovery library would be the same as the other patches I sent out.
> I was thinking of taking the approach of moving one symbol, fixing
> everything, then repeat.
>
> Does that seem like the right approach?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/9c67c30c/attachment.html>

> On Nov 6, 2014, at 4:52 PM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> I think for the main goal of cleaning up the Mac-specific hack, a
CrashRecovery library would work equally well. Juergen is more familiar with the
WebKit side of things, so he may be aware of something I’m not thinking of.
> 
> Chandler, does splitting out a CrashRecovery library instead seem sane?
FWIW, I prefer a ToolsSupport library.  It gives us the opportunity to put other
tools specific things in there if we find them.  I can’t, for example, think of
the dylib needing YAML right now, although I could be wrong.

At least if we made it ToolsSupport then we wouldn’t have come back in a few
months/year and ask to rename it from CrashRecovery.

Pete
> 
> Other than code organization and naming, the general idea of splitting out
a CrashRecovery library would be the same as the other patches I sent out. I was
thinking of taking the approach of moving one symbol, fixing everything, then
repeat.
> 
> Does that seem like the right approach?
> 
> -Chris
> 
>> On Nov 6, 2014, at 3:43 PM, Reid Kleckner <rnk at google.com
<mailto:rnk at google.com>> wrote:
>> 
>> On Thu, Nov 6, 2014 at 3:22 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> The other thought I had which motivated this solution was that if we
could strip all the functionality that is only really used by tools out into a
separate library it would offer cleaner organization of code. Support seems to
often get used as a dumping ground for stuff that just doesn’t fit anywhere
else.
>>  
>> Based on your feedback and Chandler’s maybe this just isn’t the right
separation. I can look into a solution to address our hackiness without creating
a separate library.
>> 
>> What other stuff do you think belongs in ToolsSupport that doesn't
belong in Support? Looking back at the initial email, you have command line
parsing and ToolOutputFile.
>> 
>> We could split out command line parsing, but it doesn't seem worth
it, given that we're still carrying regex support, Unicode conversion,
dynamic library support, and other things that probably aren't absolutely
necessary.
>> 
>> What about splitting out a CrashRecovery library instead? That seems a
lot more targeted and meaningful. We'd probably put ToolOutputFile.cpp in
there.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/98359545/attachment.html>

Here is my limited perspective on this topic:

1. I would like to see some of the code in LLVM's ADT and Support libraries
available for reuse in other projects. This also has some potential for
being useful to Clang -- one could imagine a world where Clang directly
linked the ADT & Support libraries, but used the compiler itself via a
clear dynamic-library vended API (which would be unrealistic to expect the
ADT & Support libraries would ever want to provide).

2. I agree with Chandler in that I don't see a good need to try hard to
factor out code from the Support library that can just be conditional
disabled or would be unused by normal .a link semantics. For example,
whether or not the regex or YAML code belongs in Support doesn't seem worth
worrying too much about, because they are very isolated, don't introduce
extra dependencies, and won't be linked by projects that don't use them.

3. I also see a good argument for having a ToolsSupport library, as a place
for all of the very-LLVM(the compiler) specific functionality that would
have no place in a shared Support library (for any number of reasons: lack
of generality, invasiveness, or because they add substantial other
dependencies).

 - Daniel


On Thu, Nov 6, 2014 at 6:53 PM, Pete Cooper <peter_cooper at apple.com>
wrote:
>
> On Nov 6, 2014, at 4:52 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
> I think for the main goal of cleaning up the Mac-specific hack, a
> CrashRecovery library would work equally well. Juergen is more familiar
> with the WebKit side of things, so he may be aware of something I’m not
> thinking of.
>
> Chandler, does splitting out a CrashRecovery library instead seem sane?
>
> FWIW, I prefer a ToolsSupport library.  It gives us the opportunity to put
> other tools specific things in there if we find them.  I can’t, for
> example, think of the dylib needing YAML right now, although I could be
> wrong.
>
> At least if we made it ToolsSupport then we wouldn’t have come back in a
> few months/year and ask to rename it from CrashRecovery.
>
> Pete
>
>
> Other than code organization and naming, the general idea of splitting out
> a CrashRecovery library would be the same as the other patches I sent out.
> I was thinking of taking the approach of moving one symbol, fixing
> everything, then repeat.
>
> Does that seem like the right approach?
>
> -Chris
>
> On Nov 6, 2014, at 3:43 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Thu, Nov 6, 2014 at 3:22 PM, Chris Bieneman <beanz at apple.com>
wrote:
>>
>> The other thought I had which motivated this solution was that if we
>> could strip all the functionality that is only really used by tools out
>> into a separate library it would offer cleaner organization of code.
>> Support seems to often get used as a dumping ground for stuff that just
>> doesn’t fit anywhere else.
>>
>
>
>> Based on your feedback and Chandler’s maybe this just isn’t the right
>> separation. I can look into a solution to address our hackiness without
>> creating a separate library.
>>
>
> What other stuff do you think belongs in ToolsSupport that doesn't
belong
> in Support? Looking back at the initial email, you have command line
> parsing and ToolOutputFile.
>
> We could split out command line parsing, but it doesn't seem worth it,
> given that we're still carrying regex support, Unicode conversion,
dynamic
> library support, and other things that probably aren't absolutely
necessary.
>
> What about splitting out a CrashRecovery library instead? That seems a lot
> more targeted and meaningful. We'd probably put ToolOutputFile.cpp in
there.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141107/9f8dab7b/attachment.html>