[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER
From: |
Thien-Thi Nguyen |
Subject: |
Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER |
Date: |
Wed, 13 Mar 2002 01:26:59 -0800 |
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
- snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER,
Thien-Thi Nguyen <=
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Marius Vollmer, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Rob Browning, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/13
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Rob Browning, 2002/03/14
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Marius Vollmer, 2002/03/14
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/14
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Marius Vollmer, 2002/03/14
- Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER, Thien-Thi Nguyen, 2002/03/14