Notably absent from this release is the work on Grantlee::Tubes. The QIODevice API needs a bit more research, so those classes will appear in a future release instead while I figure out what parts of the QIODevice API can be relied upon.
Much of the directed effort in this release has been on the build system. With the help of Alex Neundorf, the entire CMake system was updated to make Grantlee easier for consumers to consume. This includes installing EXPORTS from Grantlee which can be imported with find_package, proper RPATH handling, and reducing hardcoded paths in convenience properties.
A follow-on from the CMake work was to add some CPack configuration. Now it is possible to create binary tarballs for Grantlee as well as a Windows install wizard. CPack makes the process very easy once everything is set up.
In an effort to make generation of content where whitespace is not insignificant, I’ve added a smartTrim feature to Grantlee (based on an idea in the Django bug tracker which I’ve been pushing forward simultaneously). The idea is to discard insignificant whitespace while processing the input content. Whitespace can be considered insignificant if there is only one piece of template syntax on a line.
This feature should make it easier to write templates to generate C++ code for example. For html output, whitespace is rarely significant.
The efforts around introspection of QObject derived types in QVariants did not lead to improvements in Qt4. It is possible that improvements will be made to the introspection system in Qt5, but the features could not be added in a binary compatible way in Qt4. The Qt4 solution is more documentation.
I also added some more documentation on the examples shipped with Grantlee along with links to the brilliant prose in these blog entries.
GCov based coverage data is now also going to be produced for each release. The existing coverage data shows that Grantlee has excellent test coverage in most parts – 90% of functions are covered and 85% of lines in the libraries and plugins. Most of the non-covered code indicates missing tests for failure cases, but the ‘happy path’ is generally well covered. There might be some advantage to using CTest and CDash for coverage information. Something Grantlee coverage scripts can do that I don’t think CTest can though is to break down the coverage data by the unit test that contributed to it. This might help identify where a completely new test is needed to purposefully cover a class.
Because much of the effort in this release went into improving the buildsystem, it should be much easier now to add new libraries to Grantlee, so I expect that to happen in the next release with Grantlee::Tubes.