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

[Arseny Kapoulkine via llvm-dev]

> 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.

Sorry about that. I was initially planning to work on a patch to enhance
the interface for new lld - hence my questions in the original post. Since
I learned that people writing the code for lld are hostile to the idea of
linker-as-a-library, error_code is treated as spaghetti (which would be
fine if LLVM used exceptions which it does not) and patches, even if
submitted, will not actually be reviewed in a timely manner, I'll try to
adapt my code to either not use lld or use lld-as-a-binary.

I'm disappointed by all of this but obviously it's not my project so I
should not have a say in this.

Thank you for your time.

Arseny

On Thu, Jan 21, 2016 at 8:44 PM, Rafael Espíndola <
rafael.espindola at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/6414fc61/attachment.html>