From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER Date: 13 Mar 2002 20:15:48 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <877kognusb.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016046939 2987 127.0.0.1 (13 Mar 2002 19:15:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Mar 2002 19:15:39 +0000 (UTC) Cc: guile-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16lEDq-0000m5-00 for ; Wed, 13 Mar 2002 20:15:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16lEDX-0005kb-00; Wed, 13 Mar 2002 14:15:19 -0500 Original-Received: from dialin.speedway42.dip134.dokom.de ([195.138.42.134] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16lEC8-0005fe-00 for ; Wed, 13 Mar 2002 14:13:52 -0500 Original-Received: (qmail 1258 invoked by uid 1000); 13 Mar 2002 19:15:48 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:18 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:18 Thien-Thi Nguyen writes: > From: Thien-Thi Nguyen > 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. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel