Here's a rookie answer with some additional questions for experts:

Presuming you already have the generator set up saying that type CPP can be generated from types XML and XSLT (analogous to the stock rules that generate EXE from sources of types OBJ and LIB) using actions gen-cpp, you can put logic in your action rule block more or less like the following:

rule xml-sources-in ( sources * )
{
local xml-souces ;
...
# What's the best jammer way here to cull the .xml sources?
return $(xml-sources) ;
}
rule xlt-sources-in ( sources * )
{
local xlt-souces ;
...
return $(xlt-sources) ;
}

rule gen-cpp ( targets * : sources * : properties * )
{
XML-SOURCES on $(targets) = [ xml-sources-in $(sources) ] ;
XSLT-SOURCES on $(targets) = [ xslt-sources-in $(sources) ] ;
# Experts: Is there a more direct jammer way to do the above that would
# not require xml-sources-in and xslt-sources-in rules?
SP on $(targets) = " " ;
}
actions gen-cpp bind XML-SOURCES XSLT-SOURCES
{
$(TOOL) -IN$(SP)$(XML-SOURCES) -XSL$(SP)$(XSLT-SOURCES) -out$(SP)$(<)
touch -r $(XML-SOURCES) $(<)
}

Use similar approach for generating HTM type.

Experts, did I miss anything? Would you have discriminated further upstream in the generator to automatically populate XML-SOURCES and XSLT-SOURCES for the actions block and obviate the need for all the noise above? (I anticipate a YES answer to that.)

Cheers,
Mark

Daniel Einspanjer <deinspanjer@gmail.com> wrote:

In our make files, we have something like the following targets:

==================================
attrs: attrs.cpp attrs.htm

attrs.cpp: attrs.xml attrs.xslt
$(JAVA_HOME)/bin/java org.apache.xalan.xslt.Process -IN attrs.xml -XSL
attrs.xslt -out $@
touch -r attrs.xml $@

attrs.htm: attrs.xml attrstohtml.xslt
$(JAVA_HOME)/bin/java org.apache.xalan.xslt.Process -IN attrs.xml -XSL
attrstohtml.xslt -out attrs.htm
touch -r attrs.xml $@