That way, we have a common library to pull in from the main repository,
and a space for testing new code (in a partial implementation).
Next there will be generated object structures.
That way, the makefile doesn't need to know that much anymore, and
gets simpler/less verbose.
\# Also
* Added filters for rust doc string
* fixed .PHONY
It's quite final, and super easy to change and to read.
It seems we want to use namespaces/shared implementations soon to allow
using defs. In our case, we transform the version in a particular way,
which is easy enough, yet I'd like to use it to make the system more
powerful.
That way, we read the data files only once, but produce all the outputs
we need. Together with a powerful makefile, we have a multi-invocation
with proper depedency tracking.
Everything will be regenerated though, even though just a single input
template file changed.
The alternative would be to have one dependency and invocation per
input dependency, but that will read the entire json each time.
Let's see what's faster/more useful during development.
After minor modifications to pyratemp, it certainly does the job.
What it **does NOT** do:
* multiple outputs per template/command invocation
* NICE embedding of code (like GSL can)
It will do the job nonetheless, but mako might be worth a look
As GSL failed in my first attempt to get the example program going,
it might be better to try something else before too much time is spend.
Fortunately, pyratemp **seems** to be something usable, and even if not,
it might be possible to make it usable as it's just a 'simple'
python script that I might be able to understand, if need be.
