This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH][libcpp] New deferred output pragma


Folks,

Thanks for your comments on these patches.

Unfortunatly we can't afford to spend the time on re-writing this as a
plugin. We took a pragmatic and simple approach to get a facility we
needed and it works well, for our purposes at least.

We thought/hoped others might find it useful, but if you want to keep
the processor unchanged we'll just have to keep it in our private port.

Also - for various legal reasons (please don't ask for details!) we
can't use the plugin mechanism as it confuses our legal department ...

-----Original Message-----
From: Basile Starynkevitch [mailto:basile@starynkevitch.net] 
Sent: 13 April 2010 21:11
To: tromey@redhat.com
Cc: David Stubbs; gcc-patches@gcc.gnu.org; sdkteam-gnu
Subject: Re: [PATCH][libcpp] New deferred output pragma

Tom Tromey wrote:
>>>>>> "David" == David Stubbs <stubbs@IceraSemi.com> writes:
> 
> David> I can provide a fuller example if necessary, but it's quite a
> David> unique use case.
> 
> Just so there is no doubt, for me this doesn't meet the bar for a new
> extension.

I probably agree with such a position (even if I found the proposed 
extension a little interesting, but probably not enough to be accepted 
as is). However, this brings another question in mind: making this 
extension & patch a plugin.

I don't know enough libcpp/ & I did not looked very closely into the 
patch. However, I believe that such a need is typical for plugins.

Then the question becomes: does the current trunk provides enough plugin

hooks to make such a plugin? I would guess that some hooks are missing 
(but I am not sure of that: we have plugin hooks for pragmas, but 
perhaps not inside libcpp).

I would hence invite the IceraSami people needing this patch & deferred 
output pragma to:

   a. investigate what (small) plugin hooks might be missing to 
implement their extension as a plugin.

   b. propose (if needed) to GCC the small patch providing the necessary

extra hooks. (I would expect such a patch to be much much smaller than 
their original one, and probably easier to be accepted)

   c. implement their new pragma in a plugin, and distribute that plugin

under GPLv3 license.

Cheers.
-- 
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} ***


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]