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: 15 Mar 2002 22:12:05 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <87zo19lemy.fsf@zagadka.ping.de> References: <877kognusb.fsf@zagadka.ping.de> <87vgbzx8y7.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016227076 26872 127.0.0.1 (15 Mar 2002 21:17:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2002 21:17:56 +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 16lz5H-0006zK-00 for ; Fri, 15 Mar 2002 22:17:55 +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 16lyzd-0003aw-00; Fri, 15 Mar 2002 16:12:05 -0500 Original-Received: from dialin.speedway42.dip89.dokom.de ([195.138.42.89] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16lyxc-0003T7-00 for ; Fri, 15 Mar 2002 16:10:00 -0500 Original-Received: (qmail 1467 invoked by uid 1000); 15 Mar 2002 21:12:05 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 39 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:71 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:71 Thien-Thi Nguyen writes: > From: Marius Vollmer > Date: 14 Mar 2002 20:09:36 +0100 > > > 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. > > Sorry, I was confused. I still am, for that matter. How can it > happen that during > > guile-snarf foo.c >foo.x > > the file foo.x does not exist? It should get created by the shell > before guile-snarf is executed. Ouch. Boy, I was really really dense here. Of course the actual command that is run is not "guile-snarf foo.c >foo.x" but guile-snarf foo.c >foo.tmp.x && mv foo.tmp.x foo.x No fancy buffer issues or race conditions needed to explain the lossage... People have been using the #ifdef SCM_MAGIC_SNARFER trick to work around this, and we need to make that fix work again. I now also understand why writing to stdout is so bad and why the "-o" option is so much better. (it's taken a while, sorry Thien-Thi.) > Yes, but it is still easier not to change existing code that makes use > of the old behavior of guile-snarf. > > here, the code that needs changing is primarily in makefiles, which are > not as big a pain to update as C source, there being fewer makefiles > than source files typically. But it's still easier not to change the snarfing rules. Arguing for an evil by citing a larger, unrelated evil is not really convincing. ;-) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel