UNIX philosophy is
not learning how to use the program, but learning how the program can help you use your computer
re: UNIX philosophy is
@Satsuma has heard me go on long rants about how static site generators are failing indies because every single time it’s “how do i teach the program how to make the thing i want” not “how does the program help me teach my computer…”
every time you switch programs it’s just an entirely new set of fucking rules
re: UNIX philosophy is
@Lady have you heard of sblg
re: UNIX philosophy is
@aescling i have not
re: UNIX philosophy is
@Lady static blog generation tool that expects you coordinate it with Makefiles
re: UNIX philosophy is
@aescling nice, i already coordinate all my static site generation with makefiles
re: UNIX philosophy is
@aescling you read my blogpost right
re: UNIX philosophy is
@Lady not fully
re: UNIX philosophy is
@Lady oh right i do remember getting far enough to think about how touch(1)ing .grass would be redundant if the Makefile is sufficiently aware of sources and targets (and in fact, sblg documentation shows how to do that with the tool!)
re: UNIX philosophy is
@aescling yes, assuming that git ignores all build output you can do a subshell call in the makefile to get a list of targets and use that to build a bunch of rules for making those targets from their sources and then use a subcall to make to see if any targets are out of date before allowing a sync
or you could just touch .grass
re: UNIX philosophy is
@aescling this one doesn’t touch grass: https://git.ladys.computer/Shrine/blob/live:/GNUmakefile
re: UNIX philosophy is
@Lady owo
re: UNIX philosophy is
@aescling i absolutely am planning on doing this level of complexity when i get around to building my encyclopedia software (and i'll look into sblg to see if it can help with that) but for a simple static site it's a lot easier to just regenerate every file on every make and not worry about any of the rest of it