Thien-Thi Nguyen <[email protected]> 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: <xcb header="xproto"> <struct name="struct" /> </xcb> 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 <xcb> tag gets compiled into the (define-module ...) expression and the fictitious <xcb-2> 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
