Steven Bosscher wrote:
On Sat, Nov 7, 2009 at 11:49 AM, Basile STARYNKEVITCH
<bas...@starynkevitch.net> wrote:
Richard Guenther wrote:
Ah, you mean like doing the tuples conversion as plugin? Or to
build the cgraph infrastructure and IPA optimization infrastructure
as plugin? I guess what you say is - "stop developing gcc! develop
plugins!"?
To be more precise, I believe that some few plugins (not the ones I Basile
will write) might perhaps replace the branch role as experimental ground
for GCC. And I don't see any issue here, on the contrary. Plugins are for
their users perhaps easier to try than a whole GCC branch. What's the
difference between writing a plugin and writing a branch nobody will use? So
perhaps people would start plugins instead of starting their branch. Why
should that be bad? I feel it is very positive!
Because it encourages forking, especially because of...
Not really.
(Historically, GCC had few forks, EGCS mostly. And forks are possible because of the GPL. The FSF copyright don't
disallow them. Look at Xemacs vs Emacs, or SXemacs vs Xemacs. GPL-ed forks of GCC are inpractical, because GCC is too
big.. They are not prohibited by legal means. Of course I am not a laywer and may be wrong.)
My view is more pragmatical. Getting the FSF copyright is really a hard effort (nothing to do with coding; a lot to do
with lawyers and other people with which communication is difficult for a hacker.). So it is a *huge* barrier to enter
the GCC community. It is so big a barrier that I know several persons who gave up. So I am convinced it is a barrier
which restrict the arrival of new GCC hackers. I believe that if some Joe Hacker did develop a GPlv3 GCC plugin, then if
the plugin has some success -this is two big ifs so is not probable but it could happen- he would later want to push
that plugin into GCC core [or at least parts of it] and to transfer copyright to FSF. But getting that it that order
-Joe Hacker do have a concrete, running, useful, GPLv3 plugin already [this is more than a year of interesting work],
and Joe Hacker want to push it into GCC, and so Joe Hacker need to transfer copyright to FSF [this is 3 months of boring
work] - is in my guess less hard than getting a paper signed before coding the very first line of code. It is simpler
for a lawyer to understand that some particular existing GPLv3 piece code should be transfered to FSF that to sign a
contract on unidentified future source code.
I insist that the copyright to FSF transfer is a big brake to enter GCC
development. And this brake is not effective inside plugins. Plugins can be
simply GPLv3, but not FSF copyrighted. I am sure it makes an important
difference for putative developpers (more precisely for their bosses).
...this. If you don't like to transfer copyright to the FSF, fine.
But don't expect the FSF GCC program (i.e. us) to assist you in
subverting itself.
Plugins should add special functionality that is needed for some niche
application of GCC, but not replace internals of GCC itself.
I entirely agree, and all the MILEPOST & ICI effort are a niche application
(and also MELT).
Besides, both MILEPOST & MELT are FSF owned branches of GCC. [Nobody cares].
I can phrase my views in another way. I don't know much about ICI, but the few things I understood about ICI make me
believe (half blinded believe, I don't understand the details) that ICI could be useful for GCC. There is a copyright
transfer between INRIA (I mean the people behind ICI) and FSF. So no legal issues here.
Assuming that some parts of ICI could be useful to GCC, how can we help them in
that process?
If they try to send a big patch, I am certain nobody will review it. So ICI people could send big patches -they already
did that- and nobody is listening.
My suggestion to ICI friends is : just propose quickly your needed plugin
events, and make your ICI a GPLv3 plugin.
When you can show that your ICI plugin to an *unmodified* gcc-4.5 brings some value, GCC people will perhaps start to
listen and look inside.
The points are:
* nobody cares about experimental GCC branches (FSF copyrighted), and nobody looks inside, unless the branch happens to
be created by some major GCC guru guy like Diego Novillo or Richard Guenther or Steven Bossher or Joseph Myers (or a
dozen of important GCC guys). But branches created by some random hacker like me Basile or ICI people are virtually
non-existent. Nobody cares about them, nobody retrieves them, nobody builds them, nobody looks inside them. I am
entirely sure that if I put a naughty joke in some comment of my MELT branch, nobody would notice. But I won't do that
anyway... Also, even if there is some brillant idea in some experimental GCC branch, nobody will be aware of it. So in
my view most branches are only random bytes on disks. Likewise, nobody care about a thousand line patch sent by ICI.
* plugins are hopefully much easier to build than branches (because they are much smaller). So I hope that plugins will
be a bit more used than experimental branches (which in my view are never used). They wont be a world-wide success
neither. Let's hope a dozen users for a successful plugin. An experimental branch has 0 users, a successful GCC guru
created breanch don't have many users neither.
As a case in point, look into Graphite: it took many years to people like Sebastian Pop to go from a prototype branch to
inside the trunk (and Graphite won't be used much, if it is in -O3 only). My guess is that the plugin facility will
make that transition a bit less painful. Because using a plugin is less hard than using a branch.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
