From: Thien-Thi Nguyen <ttn@giblet.glug.org>
Cc: guile-devel@gnu.org
Subject: Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER
Date: Wed, 13 Mar 2002 13:28:39 -0800 [thread overview]
Message-ID: <E16lGIZ-0005pk-00@giblet> (raw)
In-Reply-To: <877kognusb.fsf@zagadka.ping.de> (message from Marius Vollmer on 13 Mar 2002 20:15:48 +0100)
From: Marius Vollmer <mvo@zagadka.ping.de>
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@".
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-03-13 21:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 7:51 snarfer guard macro name decision: SCM_MAGIC_SNARFER Thien-Thi Nguyen
2002-03-13 9:26 ` Thien-Thi Nguyen
2002-03-13 19:15 ` Marius Vollmer
2002-03-13 21:28 ` Thien-Thi Nguyen [this message]
2002-03-13 22:00 ` Rob Browning
2002-03-13 22:58 ` Thien-Thi Nguyen
2002-03-14 0:12 ` Thien-Thi Nguyen
2002-03-14 5:44 ` Rob Browning
2002-03-14 18:48 ` Marius Vollmer
2002-03-14 20:44 ` Thien-Thi Nguyen
2002-03-14 23:35 ` Marius Vollmer
2002-03-15 4:26 ` Thien-Thi Nguyen
2002-03-15 15:56 ` Thien-Thi Nguyen
2002-03-15 21:19 ` Marius Vollmer
2002-03-14 5:56 ` Thien-Thi Nguyen
2002-03-14 6:58 ` Rob Browning
2002-03-14 7:17 ` Rob Browning
2002-03-14 9:32 ` Thien-Thi Nguyen
2002-03-14 23:40 ` Marius Vollmer
2002-03-14 19:09 ` Marius Vollmer
2002-03-14 22:43 ` Thien-Thi Nguyen
2002-03-14 23:31 ` Rob Browning
2002-03-15 21:12 ` Marius Vollmer
2002-03-15 21:33 ` Rob Browning
2002-03-15 21:58 ` Marius Vollmer
2002-03-17 17:07 ` Rob Browning
2002-03-18 0:07 ` Marius Vollmer
2002-03-18 2:52 ` Rob Browning
2002-03-20 21:11 ` Marius Vollmer
2002-03-21 16:23 ` Rob Browning
2002-04-24 20:07 ` Marius Vollmer
2002-04-24 20:42 ` Rob Browning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16lGIZ-0005pk-00@giblet \
--to=ttn@giblet.glug.org \
--cc=guile-devel@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).