guile-devel
[Top][All Lists]
Advanced

[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 13:28:39 -0800

   From: Marius Vollmer <address@hidden>
   Date: 13 Mar 2002 20:15:48 +0100

   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?

yes.  (but this is only one issue.)

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

yes, but only if you know the name of the output file.

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

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.  however, it looks like the aix cpp
needs this file to be non-empty, which cannot be done when executing
echo and cpp (in any sequence) under the process "guile-snarf" since the
shell may buffer subprocess output.

you can require the makefile to "echo > foo.x" before invoking
guile-snarf, as another workaround, but all these workarounds (including
the "|| { rm $@; false; }" cruft) indicate to me that guile-snarf usage
should be at a higher abstraction...

   When it is easy to do (and I think it is), we should support writing
   to stdout.

it is easy to do but not easy to use.  i've come to think guile-snarf
usage is in the same vein as gcc wrt output files -- if things go wrong,
you want the program to handle things rather than having to clean up
after it, manually.  you don't see makefiles with rules like:

   gcc -c $< > $@ || { rm $@; false; }

(although maybe secretly everyone wishes this were the case?!)  doc
snarfing, on the other hand, practically begs further processing, so
writing to stdout for that process is much more desirable.  we'll get to
that sooner or later...

see below for commentary (not yet checked in -- testing continues) for
guile-snarf.

thi


______________________________________
# Usage: guile-snarf [--compat=1.4] [-o OUTFILE] INFILE [CPP-OPTIONS ...]
#
# Process INFILE using the C pre-processor and some other programs.
# Write output to a file, named OUTFILE if specified, or STEM.x if
# INFILE looks like STEM.c, and no OUTFILE is specified.  Ignore
# lines from the input matching grep(1) regular expression:
#
#       ^#include ".*OUTFILE"
#
# If there are errors during processing, OUTFILE is not written
# and guile-snarf returns non-zero.
#
# Optional arg "--compat=1.4" means emulate guile-1.4 guile-snarf.
# This option is not fully tested -- see Guile reference manual.
#
# If env var CPP is set, use that value instead of the C pre-processor
# determined at guile configure-time: "@CPP@".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]