So far I have been generating the C code with many small perl here documents, and interpolating perl variables as needed.

It looks like Template Toolkit can do his with ease. But most of the toolkit documentation seems to be about embedding logic into the template.

I think I would like to keep the logic outside of the templates, in the perl code. Am I missing something, is this a design trap?

If I use the Template Toolkit in such a simplistic manner, is there still and advantage over a bunch of here documents?

Somehow I feel like a novice again as I write perl that writes C. I have used HTML::Template for web work and written a ton of C code for signal processing, but now I am starting over again.

What matija says about HTML::Template is true, in fact, any templating system will most likely fit the bill, personally, I like Petal, but that one has some Unicode bugs and XML quoting bugs, and requires your templates to be wellformed XML, which is most likely not what you want.

At the moment, I only see two special needs for templating, string interpolation and recursive macros.

For (intelligent) string interpolation, you will want to pass in any Perl scalar and have it automagically quoted correctly as a C string, in the same way that HTML::Template can automatically URL-encode or HTML-encode any scalar variable.

While the C macro preprocessor can also take some of the work, it might be useful for you to have recursive macro calls in your templating system, especially if you want to construct complex macros from smaller parts or move all OS logic out into separate templates instead of cluttering your output with huge nested blocks of #IFDEF.

I would start out with HTML::Template, code in the C-string-quoting function, and write the first generation templates in that. Then you will find out what additional functionality you need, and can move to the second incarnation.

If you want to keep the logic outside the template, then use HTML::Template. While it was originaly designed for generating HTML (as the name implies) there is nothing in it's makeup or functionality that is specificaly tied to HTML. I've used it to generate general text documents, and I can't see any reason why it couldn't be used to generate C code.

The biggest advantage of using a template module over the HEREDOCS is the ease with which you can substitute the templates to generate differnt output for whatever reason you might need to:

• Change the code fragments that are generated to test optimised C code
• Switch the language that is generated (Or add another!)
• Use the same information to build documentation/diagrams

The biggest advantage of encapsulating the "display" logic in the templates is that it simplifies the responsibilities of your application to:

1. acquire input
2. build the graph
3. select a template
4. pass the graph to the template
5. write the output to disk

and insulates your application from bugs introduced by changing the display logic.

It also becomes much easier to produce all of those other formats that we might want because the templates now recieve all of the data in context and allow it to make output decicions based on the data rather than be an external holder to interpolated strings.

This would allow you to generate your C project many different ways without having to edit and re-edit versions of your application.

This allows you to maintain a parallel set of templates rather than "parallel" copies of the same application if you needed to test optimisation changes to your C code. Especially if changes to the output required changes to the display logic

    generator.pl --template=c
    generator.pl --template=c-optimise-poll

    vs
    
    generator.pl
    generator_test_c-optimise-poll.pl
[download]

In the end what technique you decide to use depends on what you really want to do with the information you have.

If you don't need all the stuff, don't bother with it, but I like it when I can write a few templates and the beginnings of a documentation outline cheap.

It makes my manager happy to have documentation, and when my managed is happy I'm usually in a better mood :)

--
Clayton

I am building my first perl module. It helps my coding to be about to % INCLUDE something % and have the something be dynamically generated by perl code... like code for testing purposes as was mentioned above or parts of a Parse::RecDescent grammar, for me. TT makes it possiblel for me to break up a long program in which the scoping limits of 'our' forces me to keep the entire contents together.

Here documents work well if all you have to do is replacing some variables. If you need more, especially conditions and loops, then the handling with here documents becomes ugly --- you may embed simpler conditions as @{[ $condition ? $foo : $bar ]}, but often you have to split the here doc into multiple parts.

Regarding keeping the logic outside: most, if not all templating systems work by receiving their data from the outside and doing only the output work. Some templating systems additionaly have more features (up to a [% PERL %] directive to embed perl code), but it's up to you to use them or not.