Re: Converting the gcc backend to a library?

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <10663.947479149@upchuck> Jeff wrote:
>
>  In message <20000109183223.A19523@wolery.cumb.org>you write:
>  > I wonder if this legal can of worms couldn't be sidestepped entirely by
>  > splitting things up in a different way.  Suppose we split the optimizer
>  > and back end out to a separate *program*, that reads an intermediate
>  > representation from a file.[2] 

>RMS strictly forbids this kind of support in the compiler.  Again, this
>is not a change we can accept into GCC.

This is a fact we have to live with, but personally, I find this to be very
much stupid from a technical point of view, and utterly paranoid.

>The basic idea is if there is an IR that can be read/written, then it becomes
>possible for people to write proprietary front-ends, optimizers & backends
>which communicate with GPL'd code via files using that IR.

...which is not the great harm it's said to be.  It even would have some
benefits for gcc proper.  Heck, free tools can compete with commercial
competition, and win. It's mostly a question of writing *better* tools
than the competition.

(If it were such an utter catastrophe, then I guess that OpenBSD, FreeBSD
and NetBSD would have vanished from existence a few years back...)

This is a real shame, because this is putting political arguments right in
front of technical merit.  If it weren't for that stupid prohibition, I guess
that gcc might have been revamped that way years ago, and then the interface
might be much cleaner, well defined, and everything.
Heck, I'd wagger lots of the efforts invested into building *other* free
syntax analyzers/various checkers/pretty printers would have leveraged the
existing code-base, and what we would have would be much more exciting
than this huge mammoth of a beast we are trying to domesticate and keep
sane.

Not wanting this to degenerate into a flamewar, but I had to get this
off my chest...