I use Nikola. On the tech side the developer decided to model it as a series of tasks such as render photos, render posts, build rss etc. Those tasks are also implemented to run incrementally. For example if you add a new post then only that new post gets rendered to the output directory.
While this sounds fine in principle, it soon gets messy. A configuration change may require everything to be rebuilt. But if you rename or delete a source file it didn't track how that ended up in the output directory so you end up with a slow accumulation of crud. It turns out to be fairly easy to confuse all the incremental logic and end up with messy builds. Add poor decisions like using the datestamp of items in the output directory to build the sitemap (they don't set output directory datestamp to that of the input items) and you get important failings.
In my opinion, incremental builds should give the same results as full clean builds or you have a fragile non-repeatable build - something that is very undesirable. I wrote a bit more at http://www.rogerbinns.com/blog/on-nikola.html
I started with Nikola because of familiarity. I use the Python-centric Sphinx tool for documentation in all my work and personal projects. The primary author of Nikola also wrote rst2pdf which integrates into Sphinx if you also want to build your doc as pdf.
Nikola takes the same approach as Sphinx - for example defaulting to rst content and using conf.py for configuration. It also has reasonably complete functionality like blog posts, regular pages, arbitrary content, galleries, comment system integration etc.
Unfortunately the engineering choices over incremental builds as well as some others (eg choosing javascript/lightbox plugin that doesn't support swiping on mobile even though I pointed to one that worked exceptionally well) means I am on the lookout for an alternative. Worst case I'll probably write something that uses the Nikola file structure but makes better choices.
BTW I used Google+ for a while until they frustrated me by making it harder and harder to actually read content, plus not supporting things like RSS feeds and killing Reader. http://www.rogerbinns.com/blog/all-change.html
How can you ensure that a fresh build on a new machine gives the same result? I can see how you can guarantee the same result in terms of file contents, but not on the file modification timestamp. e.g. if I have access to the last build it is easy to verify whether a configuration change actually resulted in modified output by comparing the file contents, meaning the last modified time can remain unchanged. When building from scratch, surely you have to assume the last modified time is the time of the build. Any thoughts?
A simple approach is to generate output to a temporary file (or memory) and only overwrite the output file if that temp file differs. When no output file exists or they differ, set the timestamp to the newest of the relevant input files.
The problem here is generating a sitemap using timestamps from output files (which are volatile) instead of the input content file. Since it tries to do incremental builds that means there are files already there that it didn't generate with the current build so nothing is known about them other than what can be gleaned from the filesystem.
So you set the output timestamp to the newest of the relevant input files as I mentioned. For example a blog post output file has as input the content file, configuration settings and templates. The output timestamp can be set to the newest of those.
Or the sitemap can use the input files to get the timestamps in which case the timestamps of files in the output directory won't matter. They would affect if-modified-since so it is preferable to have them deterministic.
While this sounds fine in principle, it soon gets messy. A configuration change may require everything to be rebuilt. But if you rename or delete a source file it didn't track how that ended up in the output directory so you end up with a slow accumulation of crud. It turns out to be fairly easy to confuse all the incremental logic and end up with messy builds. Add poor decisions like using the datestamp of items in the output directory to build the sitemap (they don't set output directory datestamp to that of the input items) and you get important failings.
In my opinion, incremental builds should give the same results as full clean builds or you have a fragile non-repeatable build - something that is very undesirable. I wrote a bit more at http://www.rogerbinns.com/blog/on-nikola.html