Исправление hummer, (текущая версия) :
Не вижу какой-то особой конкуренции. В GCC многие технические решения принимаются по идеологическим причинам. Вот например, из переписки Каутского с Энгельсом:
https://lwn.net/Articles/629292/
> It is more or less the same loss. The case I'm concerned about is that
> it become normal to use GCC with proprietary add-ons.
My understanding is that people are satisfied with the current GCC
plugin licensing. What is at stake here is the development of a stable
output that gives enough info for things like refactoring.
IOW the issue is not disallowing proprietary add-ons (we're all pretty
happy to disallow them, IIUC), but making it impossible to use GCC
within a proprietary product (e.g. a proprietary IDE).
> Nowadays GCC does allow plug-ins -- we came up with a safe way to do
> it (or at least I hope it's safe). The issue now is to convince
> people to work on improvements to GCC.
Maybe that's the issue for GCC, but for Emacs the issue is to get detailed
info out of GCC, which is a different problem. My understanding is that
you're opposed to GCC providing this useful info because that info would
need to be complete enough to be usable as input to a proprietary
compiler backend.
Исходная версия hummer, :
Не вижу какой-то особой конкуренции. В GCC многие технические решения принимаются по идеологическим причинам. Вот например, из переписки Каутского со Энгельсом:
https://lwn.net/Articles/629292/
> It is more or less the same loss. The case I'm concerned about is that
> it become normal to use GCC with proprietary add-ons.
My understanding is that people are satisfied with the current GCC
plugin licensing. What is at stake here is the development of a stable
output that gives enough info for things like refactoring.
IOW the issue is not disallowing proprietary add-ons (we're all pretty
happy to disallow them, IIUC), but making it impossible to use GCC
within a proprietary product (e.g. a proprietary IDE).
> Nowadays GCC does allow plug-ins -- we came up with a safe way to do
> it (or at least I hope it's safe). The issue now is to convince
> people to work on improvements to GCC.
Maybe that's the issue for GCC, but for Emacs the issue is to get detailed
info out of GCC, which is a different problem. My understanding is that
you're opposed to GCC providing this useful info because that info would
need to be complete enough to be usable as input to a proprietary
compiler backend.