Re: snarfer guard macro name decision: SCM_MAGIC_SNARFER

[Thien-Thi Nguyen <ttn@giblet.glug.org>]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   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.

wrt when foo.x is created, we're saying the same thing.  (the "this is
not guaranteed to work" applies to the whole design -- where we need to
regard mere file availability as insufficient.)

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

the AIX problem is not that its shell buffers echo, but that its cpp
(reportedly) doesn't like to #include an empty .x file.  shells (of any
platform) buffering subprocess output could be regarded as a problem,
but is generally accepted (and desirable for obvious reasons), so we
need to re-examine our usage.

here's a simple program that tests the relevant behavior:

 #!/bin/sh
 echo hi
 cat zz

save to file z, chmod +x z, and invoke it like "z > zz".
what do you see?  on my system i see:

 cat: zz: input file is output file

and the program exits w/ non-zero status value.  substitute cat w/ some
other program that eventually needs to read zz, and it is no surprise if
that program fails.  thus, i conclude that in general this kind of usage
is the wrong way to go about things, not because cat failed, but because
this style forces us to know the intracacies of each program (e.g.,
"test -f" works, "test -s" works sometimes, etc), which is a PITA to
determine and maintain.  big lose.

we can special-case for AIX but that way lies madness.  the approach
i've taken is to look at the AIX problem as an additional constraint
that when satisfied should not burden other platforms.

   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.

(if someone installs a new guile (and new guile-snarf), they need to
modify the makefile to enable some compatibility anyway.  in the process
if they don't take advantage of the less-crufty new usage and demand
"support" for making them do more work, rather than question their
dubious judgement (and unslackful ethics) i suppose my response would be
to say that guile-snarf was never documented in the first place, and be
done w/ it.)

on the other hand, i am eager to resolve the SCM_VCELL removal issue in
favor of allowing minimal changes to C source.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel