Brendon Costa wrote:
I believe we should first focus (when the runtime license will permit
that) on making whatever plugin machinery available and merged into
the trunk (when it comes back to stage one). This is not an easy task.
Isn't the point of this discussion to decide what features to put into a
plugin framework? I.e. We need a "whatever plugin machinery available"
to exist before we can even think about merging that into the trunk and
defining what that looks like is the point of this discussion i thought.
I entirely agree. Apologies to everyone if I badly expressed myself.
Possible steps for moving forward with this:
1) Define what features we need for the first release, and think about
what we may want in the future
2) See which frameworks currently exist and how each meets the necessary
features identified
3) Either use one of the above frameworks as a base or start a new
framework on the plugin branch
4) Work on the "base set of features" for a first release
5) Make sure the branch is up to date/tracking the trunk
6) Look at merging into the trunk when licensing is complete
We are still at 1 (and partially identifying projects for 2) as far as i
understand.
I also agree. What I don't understand is if having a simple crude plugin
mechanism make it easier to be accepted in the trunk. I don't understand
what makes features & code easy to be accepted in a stage one trunk. I
don't understand if havving a small plugin machinery (there already
exists some) make it easier to be accepted in the trunk.
I still do not understand how and when big patches get accepted in the
trunk. What are the social issues involved? What is the best way to get
code reviewers (those able to approve a patch) interested by any big
plugin patch? (And FYI I am asking myself the same question for MELT:
what should I do now to get some day in the future MELT accepted in the
trunk?).
So far, i think libplugin seems to be the most "general" plugin
framework for GCC i have had a chance to look at (It was easy to look at
because it has some decent documentation online).
In practice, I think that we should first try to get some code into
the trunk which make some plugin work on some common easy host system
(Linux), and only after try to generalize the work to harder hosts.
I agree, that providing working code for only simple to implement
platforms (and basic plugin features) at first is a good idea (but do so
on a branch first, then merge that to the trunk once it is operational).
However we do not want to start with a framework that will need to be
completely redesigned in the future to later support other platforms or
usages. I.e. Thinking ahead but not necessarily implementing ahead...
I fully agree. But who thinks that the libplugin patch (or any other
plugin machinery) could be accepted into the trunk?
My main concern is plugins & passes.
Yes. We have not really looked at this more important aspect in much
detail, how to manage passes with plugins. It looks like libplugin has
some ideas for pass management that may help? Any thoughts?
Apparently they have.
But we need to have a more exact picture of what the GCC steering
commitee & the FSF wants (and even more importantly do not wants)
regarding plugins. I could imagine that they (& perhaps us) want some
tricks that make proprietary plugins impractical, but I have no idea of
what that would technically mean (because I have no understanding of the
legal & social system involved).
My hypothesis is that several plugin mechanisms for GCC already exist
(on some branches or somewhere else). If a small plugin patch has a
better chance to get accepted into the trunk, we should limit ourselves
to such a small thing. If big plugin machinery could be accepted (I
would prefer that) we should understand what would make them more
acceptable. In both cases, plugins have probably some requirements
defined by the future runtime license, which I don't know yet.
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} ***
