3 ms·

And here we should note that LLVM (by its creator who already worked on it at Apple at this point) was offered to GNU and the FSF in 2005 but were ignored/chide

And here we should note that LLVM (by its creator who already worked on it at Apple at this point) was offered to GNU and the FSF in 2005 but were ignored/chided [1] until a decade later when GCC/GNU/FSF realized what they had been offered ten years earlier and then had to grapple with what they had rejected, once LLVM had taken hold [2, 3], including proposals to try to refuse LLVM patches to emacs, out of some sense of petty NIH thing [the whole thread 2 and 3 are part of]. [1]: https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html https://gcc.gnu.org/legacy-ml/gcc/2005-11/msg00888.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00783.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... [3]: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00640.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...

emn13 5y ago
Reading those threads makes those decisions seem pretty reasonable to me; this doesn't look like a petty vendetta at all. And while chris sounded optimisitic about including LLVM, he didn't offer to; he offered the glue code to allow the gcc frontend to talk to the separate LLVM backend - and doing so implied a raising a number of fundamental requirements, such as the C vs. C++ bootstrapping issue. Accepting major changes like that isn't trivial; and a certain amount of NIH is healthy here. I mean, that's kind of apples motto too right? This was a technical patch set with unclear upside (if any), and potentially relevant cost - why would they accept that?