[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in the snarfer?
From: |
Michael Livshin |
Subject: |
Re: Bug in the snarfer? |
Date: |
05 Jun 2001 11:03:26 +0300 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) |
Ariel Rios <address@hidden> writes:
> I am getting the following:
>
> guile-snarf -DHAVE_CONFIG_H -I. -I. -I. -D_REENTRANT
> -I/usr/include/gtk-1.2 -I/usr/X11R6/include -I/usr/include/glib-1.2
> -I/usr/lib/glib/include -I/usr/local/include -I/usr/local/include
> -I/usr/local/include -g -O2 guile-gtk.c >guile-gtk.c.tmp && mv
> guile-gtk.c.tmp guile-gtk.x
> guile-gtk.c:2776: guile-gtk.x: No such file or directory
> make: *** [guile-gtk.x] Error 1
>
> I have not changed anything in gnom-guile that can cause this problem.
> I suspect the recent guile-snarfer changes might be causing problems
I'm not sure how this ever worked for you, actually.
snarfing relies on a pretty dirty trick: the fact that in a shell
redirection like this: "guile-snarf ... guile-gtk.c > guile-gtk.x"
an (empty) guile-gtk.x already exists when the snarfer script runs the
preprocessor. by redirecting to a different file (why, btw?) you
break this assumption, so the preprocessor complains.
--
... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result
is that thieves and bums use C++ and nice people use CLOS.
-- Erik Naggum