Generate the Eldev file from the ‘build.org’ file

This commit is contained in:
Tom Willemse 2023-07-25 23:26:47 -07:00
parent ca1020b4d0
commit 41c13782c8
3 changed files with 67 additions and 28 deletions

3
Eldev
View file

@ -1,6 +1,5 @@
; -*- mode: emacs-lisp; lexical-binding: t -*-
; -*- lexical-binding: t -*-
;; Uncomment some calls below as needed for your project.
(eldev-use-package-archive 'gnu)
(eldev-use-package-archive 'nongnu)
(eldev-use-package-archive 'melpa)

View file

@ -1,7 +1,11 @@
%.mk: build.org
define tangle =
eldev emacs -quick -batch \
-eval "(package-initialize)" \
-load ob-tangle \
-eval "(org-babel-tangle-file \"$<\" \"$(PWD)/$@\" \"makefile\")"
-eval "(org-babel-tangle-file \"$<\" \"$(PWD)/$@\"$(if $1, \"$1\"))"
endef
%.mk: build.org
$(call tangle)
include build.mk

View file

@ -6,34 +6,38 @@ I'm a big fan of [[file:literate-programming.org][Literate Programming]], so I f
First I need to build the build files. This is the smallest make file that I can think to make to enable me to build the rest out. This make file is duplicated in both this file and the source code repository since I don't know of a way not to.
First I specify that any =.mk= file should depend on /this/ file ({{{input-file}}}) and that it is generated by running =org-babel-tangle-file= on it. The =$<= is the first dependency and =$@= is the current target file (whatever =.mk= file we're generating).
First I define a function =tangle= that can be used to tangle an org file to the code file that it needs to be. Then I specify that any =.mk= file should depend on /this/ file ({{{input-file}}}) and that it is generated by running =org-babel-tangle-file= on it. The =$<= is the first dependency and =$@= is the current target file (whatever =.mk= file we're generating).
#+begin_src makefile :tangle no
%.mk: build.org
eldev emacs -quick -batch \
-eval "(package-initialize)" \
-load ob-tangle \
-eval "(org-babel-tangle-file \"$<\" \"$(PWD)/$@\" \"makefile\")"
#+begin_src makefile-gmake :tangle GNUmakefile
define tangle =
eldev emacs -quick -batch \
-eval "(package-initialize)" \
-load ob-tangle \
-eval "(org-babel-tangle-file \"$<\" \"$(PWD)/$@\"$(if $1, \"$1\"))"
endef
%.mk: build.org
$(call tangle)
#+end_src
After that it's just a matter of including the file I want.
#+begin_src makefile :tangle no
#+begin_src makefile-gmake :tangle GNUmakefile
include build.mk
#+end_src
GNU Make (I don't know about other makes) will see if there is a recipe to make the file it wants to include and will try and run it before trying to include the file. This combined with our =%.mk= target ensures that make will always try to recreate the =build.mk= file when ={{{input-file}}}= is updated.
GNU Make (I don't know about other makes) will see if there is a recipe to make the file it wants to include and will try and run it before trying to include the file. This combined with our =%.mk= target ensures that make will always try to recreate the =build.mk= file when {{{input-file}}} is updated.
* Makefile
:PROPERTIES:
:header-args:makefile: :tangle build.mk
:header-args:makefile-gmake: :tangle build.mk
:END:
This is the actual make file that builds and deploys my site. It's all put into the =build.mk= file and executed from there. The =%.mk= pattern rule thankfully doesn't get recognized as a make target, so the first target define in the included file is assumed to be the default target.
First off I specify the =help= target. This target parses the make files and extracts targets that include some comment on what they do. This target should come first so that it automatically becomes the default target. This way when I run just ~make~ I can see which targets I have available. I got this awesome trick from [[https://victoria.dev/][Victoria Drake]]s article [[https://victoria.dev/blog/how-to-create-a-self-documenting-makefile/][How to create a self-documenting Makefile]].
#+begin_src makefile
#+begin_src makefile-gmake
help: ## Show this help
@grep --extended-regexp --no-filename '^[^#].*?\s##\s' $(MAKEFILE_LIST) \
| sort \
@ -42,21 +46,21 @@ help: ## Show this help
The =build= target converts everything from whatever source files they are to html and css. The build target has 2 other targets it depends on, not surprisingly =html= and =css=. The =html= and =css= targets don't have any comment because they're not really meant to be executed directly.
#+begin_src makefile
#+begin_src makefile-gmake
build: html css ## Build the site and copy it to the staging directory
#+end_src
The =html= target calls Emacs. It has no dependencies because the org-mode publishing method takes care of making sure that nothing gets built unless necessary.
The =html= target calls Emacs. It depends on the =Eldev= file having been generated to specify any additional dependencies and which package archives should be used and this file will be generated by the =Eldev= target.
#+begin_src makefile
html:
#+begin_src makefile-gmake
html: Eldev
@echo "Publishing..."
eldev emacs --quick --batch --load publish.el --funcall org-publish-all
#+end_src
The =css= target does specify its dependencies. This is both an exercise in writing make files (which I generally quite enjoy), and also to make sure that my builds don't take too long unless they actually have to. Ultimately any =.css= file gets created from a =.less= file by calling the =lessc= program. I'm intentionally not using recursive make in this project because it slows make down a lot, and I don't have to manage several make files this way.
#+begin_src makefile
#+begin_src makefile-gmake
css: public/assets/css/main.css public/assets/css/tekuti.css public/assets/css/cgit.css
public/assets/css/main.css public/assets/css/tekuti.css public/assets/css/cgit.css: \
@ -71,7 +75,7 @@ public/assets/css/%.css: src/less/%.less
The =deploy= target first makes sure that =build= has been executed at least once and then uses =rsync= to upload all of the files. This intentionally doesn't depend on the =build= target so that I can upload whatever I happen to have generated without being forced to rebuild.
#+begin_src makefile
#+begin_src makefile-gmake
deploy: ## Deploy the site to live
@[[ -e public/index.html ]] || (echo "Run 'make build' before deploy" && exit 1)
rsync --verbose --checksum --recursive --delete \
@ -81,26 +85,30 @@ deploy: ## Deploy the site to live
The =clean= target makes sure that everything that is generated gets cleaned up again. This is important if I need to start with a clean slate.
#+begin_src makefile
#+begin_src makefile-gmake
clean: ## Remove all of the build files
@echo "Cleaning up..."
@rm -rvf *.elc
@rm -rvf public
@rm -rvf .org-timestamps
@rm -rvf posts/index.org build.mk
@rm -rvf posts/index.org build.mk Eldev
#+end_src
The =serve= target is a convenience target for when I'm writing or making modifications to the build and publish processes. It just starts a simple =php= web server in the =public/= directory so that I can easily load it in my browser.
#+begin_src makefile
#+begin_src makefile-gmake
serve: ## Run a simple web server to look at the results
@cd public && php -S "localhost:8000"
#+end_src
The =theme= target is another convenience target. I generate the colors for the source code blocks on my site from my Emacs theme. This target exports the colors from my theme so that the code blocks can use them. This file is then included by the less files. There is no good dependency here, because there is no file for the export of my theme to depend on right now, just occasionally I have to run it.
The =theme= target is another convenience target. I generate the colors for the source code blocks on my site from my Emacs theme. This target exports the colors from my theme so that the code blocks can use them. This file is then included by the less files. There is no good dependency here, because there is no file for the export of my theme to depend on right now, just occasionally I have to run it. It does depend on the =Eldev= file having been generated.
#+begin_src makefile
theme: ## Generate the theme CSS
#+begin_info
I keep this particular target around for playing with, but right now it doesn't actually work. Just because even though I load and enable =yoshi-theme= it doesn't appear to apply the theme in a batch session. Seems understandable because no UI actually gets loaded, but that does mean that it can't figure out which faces it sets and it just outputs the colors for the default theme.
#+end_info
#+begin_src makefile-gmake
theme: Eldev ## Generate the theme CSS
eldev emacs --quick --batch --load htmlize --load ox-html \
-eval "(setq org-html-htmlize-output-type 'css)" \
-funcall org-html-htmlize-generate-css \
@ -118,12 +126,40 @@ theme: ## Generate the theme CSS
-eval '(write-file "src/less/yoshi.css")'
#+end_src
The =Eldev= target just tangles the {{{input-file}}} into the =Eldev= file. This uses the =tangle= function defined in the intro section.
#+begin_src makefile-gmake
Eldev: build.org
$(call tangle)
#+end_src
Finally, as a precaution, I specify that all of the main targets are phony targets. This way if I ever introduce any file with the same name as these targets they will still build and not assume that because the file exists, everything is up-to-date.
#+begin_src makefile
#+begin_src makefile-gmake
.PHONY: publish deploy html css help theme
#+end_src
* Eldev
:PROPERTIES:
:header-args:emacs-lisp: :tangle Eldev
:END:
With Eldev I can install dependencies of my =publish.el= locally. Really the only reason I chose to use Eldev is because it is available in the [[file:guix.org][Guix]] repository.
Since this is an actually full-fledged Emacs Lisp file and I don't know what I'm going to be doing in the future, I should be sure to enable lexical binding. Otherwise Emacs defaults to using dynamic binding, and that might cause some surprises in the future, since I'm quite used to using lexical binding everywhere.
#+begin_src emacs-lisp
; -*- lexical-binding: t -*-
#+end_src
All I'm doing here, really, is enable the various Emacs Lisp Package Archives.
#+begin_src emacs-lisp
(eldev-use-package-archive 'gnu)
(eldev-use-package-archive 'nongnu)
(eldev-use-package-archive 'melpa)
#+end_src
* COMMENT Local Variables
# Local Variables: