Thien-Thi Nguyen writes:
> Maybe the simplest way is to completely separate code generation from
> compilation. This also gives you an opportunity to do compilation in
> two places (of the code that generates the code, and of the generated
> code). So your Makefile would look like:
>
> gen: gen.scm
> $(COMPILE) -o $@ $(COMPILEFLAGS) $<
> chmod +x gen
>
> %.generated : %.xml
> ./gen -o $@ $(GENFLAGS) $<
>
> %.go : %.generated
> $(COMPILE) -o $@ $(COMPILEFLAGS) $<
That's kind of what I wound up doing via abuse of the language's #:read
property. Instead of providing a function that just gives the result
of xml->sxml to the compiler, I have it break some xml tags into
multiple tags so each one can be treated as a separate expression.
Eg. The file looks like this:
And the reader would return each of the following expressions in turn:
'(xcb (@ (header "xproto")))
'(xcb-2 (@ (header "xproto")))
'(struct (@ (name "struct")))
That way the tag gets compiled into the (define-module ...)
expression and the fictitious tag gets compiled into the (begin
...) statement that contains some module-wide definitions and so forth.
This approach stays inside of the guile 2 compiler infrastructure but it
has the disadvantage of turning what's supposed to be a simple,
single-purpose function into a bit of a stateful mess.
It would be nice if the compiler could handle multiple-value returns
from read-and-parse (assuming that doesn't harm performance... I might
try it out and see what it does).
> I am very much looking forward to learning what you discover, and
> applying it to all the projects i maintain. (For example, Guile-SDL
> test/gfx.scm is a dog under Guile 2.x, blech.) Fingers crossed...
I'll be happy to do that if I come up with something!
Thanks
--
Mark Witmer
