unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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


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