[PATCH] D26042: Consolidate BumpPtrAllocators.

[Mehdi Amini via llvm-commits]

> On Oct 28, 2016, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 28 October 2016 at 16:16, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> On Oct 28, 2016, at 1:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>> 
>>> 
>>>> On Oct 28, 2016, at 1:00 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>>>> 
>>>>> I’m fine with keeping our disagreement about the lld “style”.
>>>>> 
>>>>> Just keep in mind that this is not a direction that is “encouraging everyone” to be involved or care about lld.
>>>> 
>>>> That is fine. The objective of the new ELF linker is simple: be the
>>>> best ELF linker out there. The objective is not to have it be a
>>>> generic reusable framework os to maximize the number of people
>>>> involved in it.
>>> 
>>> Not being reusable just does not line up with what *I* would expect from a LLVM project in general. We wouldn’t have this discussion if you had started a separate linker project on GitHub.
>> 
>> To be clear: I’m just expressing a personal view and expectation here: there is nothing wrong with building an awesome monolithic linker that solves real problem otherwise (which is what I believe you are doing with lld).
> 
> Yes, that is exactly what we are doing.
> 
> And for any design (why the quotes?)

I used “design” with quote especially because this is a vague term, so the quote was intended to mark my inability to use a more accurate term here. I mean we can consider “design” of a library or an algorithm, very technical “design” choices (like the language, the use of global variable), or very high-level “design” choice (like “it is a standalone monolithic application”).

> decision there are those that
> disagree. Now, given that the people actually writing the linker
> agreed on the design, I don't see why they would not follow it because
> someone else doesn't like it.

When anyone propose a new backend, or a new LLVM subproject, there will be scrutiny. The fact that the folks who wrote the backend or this new project like different practices than what’s going on in LLVM does not give a blanket approval.

> 
> Note that is perfectly symmetrical. If you start working on a library
> with a design I disagree with, the design might prevent me from
> contributing to it. That is fine. I would not try to say that *you*
> should code something in the way *I* think is right.

This is why I used quotes around “design” :) 
Depending on what you put being the word “design” here, I may or may not disagree with this paragraph.


> Please don't try
> to force your design preference unto the people writing the ELF lld.

I am only expressing my own disagreement, it hasn’t prevented you guys from doing what you want till now, so I’m not sure where I would have “forced” anything.

— 
Mehdi





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161028/449412a1/attachment.html>