That way, a single huge markdown file containing documentation for
commands and methods can be split up into multiple files for
individual inclusion in mkdocs.
It's done by a post-processor which is loaded by mako-render, providing
access to the entire context. Said processor may also drop results
altogether and thus prevent files to be written that have been split up
by it.
... it shows that the override I used previously won't work for `admin`.
Therefore we have to keep the actual value, instead of degenrating it.
Makes sense ... it's interesting how much one tends to hard-code things
to work just for a few cases, unless you opt in to see the whole picture
This file is completely generated, and allows us to easily bring in
new versions after each json update.
To make that work, we simple merge all data handed to mako-render,
inside of it. That way, we can put 'api/list' data in any yaml.
However, this also means we need recursive builders, which is tottally
unsupported for now ... .
This means we have to generalize rbuild generation ... could be easy.
Lets see
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
Namespaces can exclusively be used during rendering, which is fine if
you remind yourself of the newline rules.
However, I also need some utiltiies that convert input data. These
are now within their own libraries, which can be used from python blocks
like the ordinary python functions they are.
Quite neat.
In future, most of the functionality will be in separate namespaces,
the top-level will just assemble the main library file, usnig the
provided %defs. That way, the main file is kept clean.
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.
Now we can write mako templates, with a similar feature set as
pyratemp. Except that its syntax is nicer, allows to do everything
and that there is syntax highlight support.
Let's see how it fares
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.
Added all prerequisite programs in binary for easier use.
Make is now implemented top-level, and is not expected to do too much
work actually. It will, however, keep track of all required
gsl invocation and make sure calls are efficient by not having
to rebuild everything every time. That's what make does, anyway ;)
