Re: [patch] libguile/eval.c

[Lars J. Aas]

On Fri, Nov 17, 2000 at 12:14:40AM +0100, Marius Vollmer wrote:
: "Lars J. Aas" <address@hidden> writes:
: > On Thu, Nov 16, 2000 at 11:09:22AM +0100, Lars J. Aas wrote:
: > : I also disabled the use of `inline' - it needs to be used through
: > : a define so it can be disabled.
: > 
: > Just forget about this part - I have a problem with config.status that
: > results in an empty scmconfig.h for the moment - I noticed this was dealt
: > with there...
: 
: It seems like you want to port Guile to a new platform.  Could you
: collect all the patches until the port is completed?

Sure.  Could you consider applying the SCM_MAGIC_SNARFER patch though?
It has nothing to do with the code port (just the build port), and
would be nice to get out of the way since it affects so many files
in libguile/.

I am not completely sure why it has to be done that way.  One would
think that running `snarfer file.c > file.x' would create an empty
`file.x' that was ready to be opened by any process before `snarfer
file.c' was run, but it doesn't.  I'm not sure if the problem is that
`file.x' doesn't exist or that it can't be opened for reading when
snarfer is run, but it's one of those and the solution was obvious -
don't include the file being generated.  I might add that the VC++
compiler (cl.exe) is invoked through a script (msvccc - an abstraction
layer for making cl.exe behave like normal compilers when it comes to
command-line options and compiler output to stdout/stderr) and all
the output is redirected to files to be processed after the run.
Consequently, invoking `msvccc -E' will run and finish the whole
preprocessing step before any output is actually produced on stdout
to be sent to `file.x'.

  Lars J