Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer <mvo@zagadka.ping.de>]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 14 Mar 2002 20:09:36 +0100
> 
>    > this is not guaranteed to work; when invoked w/ "foo > out.x", the shell
>    > does indeed create out.x first, satisfying most CPPs' requirements for
>    > out.x existing to be #included.
> 
>    Sorry, I was confused.  I still am, for that matter.  How can it
>    happen that during
> 
>        guile-snarf foo.c >foo.x
> 
>    the file foo.x does not exist?  It should get created by the shell
>    before guile-snarf is executed.

Ouch.  Boy, I was really really dense here.  Of course the actual
command that is run is not "guile-snarf foo.c >foo.x" but

    guile-snarf foo.c >foo.tmp.x && mv foo.tmp.x foo.x

No fancy buffer issues or race conditions needed to explain the
lossage...  People have been using the #ifdef SCM_MAGIC_SNARFER trick
to work around this, and we need to make that fix work again.

I now also understand why writing to stdout is so bad and why the "-o"
option is so much better.  (it's taken a while, sorry Thien-Thi.)

>    Yes, but it is still easier not to change existing code that makes use
>    of the old behavior of guile-snarf.
> 
> here, the code that needs changing is primarily in makefiles, which are
> not as big a pain to update as C source, there being fewer makefiles
> than source files typically.

But it's still easier not to change the snarfing rules.  Arguing for
an evil by citing a larger, unrelated evil is not really
convincing. ;-)

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel