Re: plugin includes for MELT

2008-03-04 Thread Ralf Wildenhues
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 06:56:35PM CET: > Ralf Wildenhues wrote: >> * Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET: run-basilys.d: run-basilys.h \ $(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) $(TM_H) $(TREE_H) $(GGC_H) \ tree-pass.h

Re: plugin includes for MELT

2008-02-28 Thread Tom Tromey
> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes: [snip] Ralf> Wasn't there a proposal to use depcomp in gcc a while ago? Yes. I'm planning to submit the automatic dependencies patch for real in a week or two. I'm working through my backlog of 4.4 patches and that is the last one. To

Re: plugin includes for MELT

2008-02-28 Thread Basile STARYNKEVITCH
Basile STARYNKEVITCH wrote: Ralf Wildenhues wrote: Hello Basile, A mere quick portability review: A big thanks Commited into MELT branch rev 132754. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencer

Re: plugin includes for MELT

2008-02-28 Thread Basile STARYNKEVITCH
Ralf Wildenhues wrote: Hello Basile, A mere quick portability review: A big thanks * Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET: compile-basilys-defs: echo '#generated compile-basilys-defs' > $@ echo 'ALL_CFLAGS="' $(ALL_CFLAGS) '"' >> $@ e

Re: plugin includes for MELT

2008-02-28 Thread Ralf Wildenhues
Hello Basile, A mere quick portability review: * Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET: >> compile-basilys-defs: >> echo '#generated compile-basilys-defs' > $@ >> echo 'ALL_CFLAGS="' $(ALL_CFLAGS) '"' >> $@ >> echo 'ALL_CPPFLAGS="' -I$(PWD) $(ALL

Re: plugin includes for MELT

2008-02-28 Thread Basile STARYNKEVITCH
Hello List (& Bcc to GlobalGCC partners) I now understand more what I need for MELT plugin inclusion. I'm rephrasing my thoughts and experiments. First, I'm recalling the general context. MELT may (see http://gcc.gnu.org/wiki/MiddleEndLispTranslator for more) generate C code during the compil

Re: plugin includes for MELT

2008-02-27 Thread Basile STARYNKEVITCH
Hello All, Basile STARYNKEVITCH wrote: I think it should be (in gcc/Makefile.in parlance) $(DESTDIR)$(libexecsubdir)/melt-private-include/ and I should have some Makefile.in trick to copy the relevant *.h there perhaps thru a install-melt-includes target The one detail I don't understand

Re: plugin includes for MELT

2008-02-27 Thread Basile STARYNKEVITCH
Hello All, Dave Korn wrote: On 27 February 2008 18:26, Basile STARYNKEVITCH wrote: So, since you are planning to compile the plugin during cc1 execution anyway, why not just say that - plugins are distributed as source Yes, exactly. And to be more precise, all MELT plugin C code is gener

RE: plugin includes for MELT

2008-02-27 Thread Dave Korn
On 27 February 2008 18:26, Basile STARYNKEVITCH wrote: > I'm trying to understand how other "plugin" related effort deals with > this. Perhaps nobody really cares, but I tend to believe that any plugin > effort should install the right *.h files outside of the source or build > directories, for pl

Re: plugin includes for MELT

2008-02-27 Thread Brian Dessent
Basile STARYNKEVITCH wrote: > I'm trying to understand how other "plugin" related effort deals with > this. In an ideal world, you create a plugin API/ABI that is decoupled from any of the internals of the main program and which has its own headers and interface. Plugin authors simply code to th

Re: plugin includes for MELT

2008-02-27 Thread Basile STARYNKEVITCH
Hello All, A big thanks to Dave Korn, who wrote: On 27 February 2008 12:57, Basile STARYNKEVITCH wrote: Practically, every MELT generated file has exactly one include directive: #include "run-basilys.h" the gcc/run-basilys.h is in the MELT branch and of course include many other files eg

RE: plugin includes for MELT

2008-02-27 Thread Dave Korn
On 27 February 2008 12:57, Basile STARYNKEVITCH wrote: > My MELT branch [originally I called it basilys] is (currently is not but > should) generate C code during the cc1 execution > The point is that every MELT generated C file is a plugin to the > middle-end hence depends upon all the middle-e