[llvm-dev] lld: ELF/COFF main() interface

[Eric Christopher via llvm-dev]

Rafael,

This is an unreasonable and unacceptable escalation of this thread. You
have been dismissive, derailing, and taking out of context everything
Chandler, and other long term active contributors have been asking and
talking about. Your tone has been inflammatory and unhelpful in what is
both a technical discussion and project discussion.

Irrespective of anything else I believe you owe Chandler an apology.

To further Chandler's arguments as far as the project is concerned, please
do keep in mind that: a) llvm is designed around being a reusable set of
libraries, b) Chandler is articulating in a very effective way what many of
us on the project see as the direction for lld. I, and others, have not
seen it as helpful to merely reply to all of his posts with a "+1" as
that's just adding additional noise - and we all get enough email.

-eric

On Thu, Jan 21, 2016 at 8:44 PM Rafael Espíndola <llvm-dev at lists.llvm.org>
wrote:

> > Also, one of the other possible motivations of using LLD directly from
> Clang would be to avoid process overhead on operating systems where that is
> a much more significant part of the compile time cost. We could today
> actually take the fork out of the Clang driver because the Clang frontend
> *is* designed in this way. But we would also need LLD to work in this way.
>
> Then go change clang and send a patch for lld once you are done. It will
> be interested to see if you can measure a single fork in an entire build.
>
> Even better, please finish the new pass manager before working on clang
> forking cc1.
>
> In any case, I have simply wasted too much time on a thread with someone
> with no patches on the new elf linker. It is really annoying that you don't
> put effort into it and seem entitled to dictate its direction.
>
> If you want to kick us out of the llvm project, please start a thread on
> llvm-dev.
>
> If you want lld to be a library, figure out how to do it without
> sacrificing lld's productivity,  error reporting and performance (no
> error_code spaghetti) and write a patch. Just don't expect it to be
> reviewed while we have actual missing features.
>
> I will go back to implementing the linker.
>
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160122/c1cbba20/attachment.html>