* 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 basilys.h
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_CPPFLAGS) ''
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) '' $@
echo
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: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la
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.
Tom
Hello All,
{sent to the gcc@ mailing list and Bcc- to GlobalGCC partners}
This email is related to the plugin includes question
http://gcc.gnu.org/ml/gcc/2008-02/msg00373.html
http://gcc.gnu.org/ml/gcc/2008-02/msg00376.html within (in particular)
the MELT branch
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-end
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
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 that
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
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
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
12 matches
Mail list logo
