Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Marius Vollmer]

Thien-Thi Nguyen <address@hidden> writes:

>    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.

The basic problem is that during snarfing, the generated *.x file does
not get created soon enough so that it can be included while scanning
the original source, right?

Would it work to just make sure that the file exists (possibly empty
or with a comment in it) when cpp is run?

I.e, just move the last "echo" in guile-snarf before the CPP
invocation.

> 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?

When it is easy to do (and I think it is), we should support writing
to stdout.  Offering the "-o" option is a very good thing, and we
should encourage people to use it, of course.