Breakdown of Pillar

Pillar is my custom static site generator, used to build this site. While my site is probably still small enough that I could build it by hand, writing my own site generator (with a custom-ish markup language) was and is a lot of fun :>

You can find the source code to Pillar in any of these places:

This page will serve not as documentation for Pillar (though if that's what you're curious about you can look through the readme in the repo linked above), but as a thorough explantion of how it works. Because I'm almost constantly working on it, I'll try and keep this as up-to-date as possible and give a general outline of what my future plans are.

Because I want this to be as specific as possible, I'll be including line numbers to reference larger blocks of code and actual code for smaller pieces which I feel deserve their own line-by-line explanations. This is, of course, highly dependent on the version of pillar, so below is a link to the exact commit I'm talking about.


Command-line argument parsing

Lines 47 to 77 reads the given command line arguments and sets three flags, should_build, debug_active, and build_all, which affect how pillar runs. If any invalid input is given, nothing is run and the program simply returns the help menu.

Config unwrapping and initial setup

If should_build is true, pillar will run. It first gets some config information (either creating a .pillar.toml file if it doesn't exist, or reading an existing config file), and uses that to find the input and output folders.

To generate pages, it iterates through all .gn files in the directory given by the config file:


for e in fs::read_dir(&config.granite_path)? {
  let entry = e?;
  // normalizes path str
  let path = format!("{:?}", entry.path());
  let path_str = slice(&path, 1..len(&path) - 1);

Begining of parsing

Header Parsing

Debug output

Granite parsing