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: Marius Vollmer
Subject: Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER
Date: 14 Mar 2002 20:09:36 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Thien-Thi Nguyen <address@hidden> writes:

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

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.

I remember seeing problems with non-existent *.x files way back then,
but I can't remember the details.  Looking at the code in guile-gtk,
it mighta just as well been an issue with the dependency computation
used by an old version of automake.

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

This is a specific problem on AIX, and the workaround need only work
on AIX, so we only need to worry about this when AIX does in fact
buffer echoes.  I would be surprised if it does...

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

Yes, but it is still easier not to change existing code that makes use
of the old behavior of guile-snarf.



reply via email to

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