Improvements to SAW Lab Proofs and Makefiles#217
Conversation
weaversa
left a comment
There was a problem hiding this comment.
Great work @djmorel! This makes the dual tasks of development and CI integration work together seamlessly, and provides some very nice examples others can build off of.
I'll approve but wait for @WeeknightMVP to have a say before merging, seeing as he submitted the original issue.
There was a problem hiding this comment.
Externalizing a LAB variable in Makefiles is nice, as it establishes a consistent process for SAW Remote API builds and proofs -- so consistent that their content after LAB=name is the same. (Except for rotl, where rotl.c would be renamed rotl1.c, and rotl3.c would be renamed rotl.c. Enumerating intermediate files and declaring the last one as the representative makes sense.) This suggests that each lab's Makefile could be DRYed to something like:
# labs/SAW/name/Makefile
LAB=name
# any other variables or rules specific to this lab
include "../prove.mk" # Nested labs would require more `..`s# labs/SAW/prove.mk
# Note: Makefile assumes user already started the SAW remote API
# $ start-saw-remote-api
# Variables to hold relative file paths
SRC=src
PROOF=proof
SPECS=specs
ARTIFACTS=artifacts
all: build
build: $(ARTIFACTS)/$(LAB).bc
prove: build
python3 $(PROOF)/$(LAB).py
clean:
rm -rf $(ARTIFACTS)
.PHONY: all build prove clean
$(ARTIFACTS)/$(LAB).bc: $(SRC)/$(LAB).c | $(ARTIFACTS)
clang -c -g -emit-llvm -o $@ $<
$(ARTIFACTS):
mkdir -p $(ARTIFACTS)|
I'm going to temporarily restore the |
Features
make prove -Cformat without the need to change directories viacdLABvariables