Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen]

   From: Thien-Thi Nguyen <address@hidden>
   Date: Tue, 12 Mar 2002 23:51:38 -0800

   in the end, it is better to migrate self-guard naming internally, and
   include that info in the data stream only (snarfing programs generate
   program fragments opaque to all re-snarfing).

unfortunately, this is not completely realizable w/o reducing
functionality.  when invoked w/ known output file:

  guile-snarf -o foo.x foo.c            # ("-o OUTFILE" is new)

snarfing can recognize #include "foo.x" and such, filtering them from
the input, but this cannot be supported when writing to stdout (unknown
output file).

so SCM_MAGIC_SNARFER rules forever!  [the Author is now duly shot. x-p]

on the other hand...

when output is written to stdout, caller typically must check return
value and delete the already written but bogus file, if the return value
is false.  this is all handled by guile-snarf -o, so why ask for this
pain?  to be precise (old vs new):

  guile-snarf $(snarfcppopts) $< > $@ || { rm $@; false; }
  guile-snarf -o $@ $(snarfcppopts) $<

this point is already conceded by the comments in guile-snarf re temp
file usage, the question is: is it ok to not support writing to stdout?

thi