Make a few changes in the toplevel src dir to help separate
templates from code. Specifically, we rename `src/mako` to
`src/generator`, and nest the mako templates inside a
`src/generator/templates` dir.
This isolates most Python code into the `src/generator/lib` dir.
This seemed easiest, especially since I also am the author of
pulldown-cmark-to-cmark :D.
Funny how things fit together sometimes. And so much better than
if I would have tried the same in pure python.
Thanks to the latest cargo 0.3.0, it's possible to keep everything
in the stanard doc output directory, which essentially collects
everything for us.
This creatly reduces the space required to hold all documentation, and
is in fact quite beatiful.
That way, changes can be tracked.
Also, we make it official.
Future checkins will only be made if major changes were done,
similar to how the APIs are handled.
Related to #64
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 can be selected for each type of program we want to build, and makes
sense for everything that is not a library.
We also tried to unify names and folders a bit more, even though there
certainly is more work to be done to be fully non-redundant.
Fixes#43
This allows us to build efficiently. CLI programs can now have their
own cmn.rs implementation, which we can test standalone with
`cargo test`.
The primary makefile currently just explicitly pulls in the type-*.yaml,
one day we could possibly put it into a loop.
Fixes#11
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
That will allow interaction between client and authentication attempts.
It also shows how cumbersome it is to deal with all these
generics ... but hey, you gotta do what you gotta do.
If boxes of pointers would be used, it would be easier to handle, but
enforces a certain memory model. That, of course, is not desired.
