The-Homebrew-Cloud/flashcard-archive
2
0
Fork 0
mirror of https://github.com/DS-Homebrew/flashcard-archive.git synced 2024-11-22 17:59:15 +01:00
Code Issues Packages Projects Releases Wiki Activity
e8f78c0956
flashcard-archive/archive/EZ-Flash/old/Makefile

27 lines
911 B
Makefile
Raw Normal View History

EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
.PHONY: package
Makefile: use $(CURDIR) directly without $(shell pwd) This fixes building on macOS.
2024-10-03 22:52:05 +02:00
export TOPDIR := $(CURDIR)
EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
export BASE := EZ-Flash/$(shell basename $(CURDIR))
export OUT := $(TOPDIR)/../../../out
export COMMON := $(TOPDIR)/../../../common-kernels
package: directory EZ-Flash_V_Kernel_1.80.zip EZ-Flash_V_Kernel_1.82.zip EZ-Flash_V_Kernel_1.83.zip EZ-Flash_V_Kernel_1.84.zip EZ-Flash_V_Kernel_1.86.zip
directory:
mkdir -p $(OUT)/$(BASE)
EZ-Flash_V_Kernel_1.80.zip: directory
treewide: use deterministic-zip https://github.com/timo-reymann/deterministic-zip This solves a logistics issue; zip files always include the modified timestamp of a file. This doesn't sound bad until you realize that GitHub Actions always re-clones the entire repository, and the timestamp is guaranteed to be different. Because of this, every time we run our Actions workflow, the zip will have a different checksum, causing git to re-commit *every single file* to the frontend repository, causing long workflow times due to the sheer size of each commit. deterministic-zip hopefully solves this issue by forcing the modified timestamp to one hardcoded in its binary, so here is to hoping we don't abuse our git repo any further.
2024-01-15 06:59:35 +01:00
cd $(TOPDIR)/EZ-Flash_V_Kernel_1.80 && zip -r $(OUT)/$(BASE)/$@ *
EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
EZ-Flash_V_Kernel_1.82.zip: directory
treewide: use deterministic-zip https://github.com/timo-reymann/deterministic-zip This solves a logistics issue; zip files always include the modified timestamp of a file. This doesn't sound bad until you realize that GitHub Actions always re-clones the entire repository, and the timestamp is guaranteed to be different. Because of this, every time we run our Actions workflow, the zip will have a different checksum, causing git to re-commit *every single file* to the frontend repository, causing long workflow times due to the sheer size of each commit. deterministic-zip hopefully solves this issue by forcing the modified timestamp to one hardcoded in its binary, so here is to hoping we don't abuse our git repo any further.
2024-01-15 06:59:35 +01:00
cd $(TOPDIR)/EZ-Flash_V_Kernel_1.82 && zip -r $(OUT)/$(BASE)/$@ *
EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
EZ-Flash_V_Kernel_1.83.zip: directory
treewide: use deterministic-zip https://github.com/timo-reymann/deterministic-zip This solves a logistics issue; zip files always include the modified timestamp of a file. This doesn't sound bad until you realize that GitHub Actions always re-clones the entire repository, and the timestamp is guaranteed to be different. Because of this, every time we run our Actions workflow, the zip will have a different checksum, causing git to re-commit *every single file* to the frontend repository, causing long workflow times due to the sheer size of each commit. deterministic-zip hopefully solves this issue by forcing the modified timestamp to one hardcoded in its binary, so here is to hoping we don't abuse our git repo any further.
2024-01-15 06:59:35 +01:00
cd $(TOPDIR)/EZ-Flash_V_Kernel_1.83 && zip -r $(OUT)/$(BASE)/$@ *
EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
EZ-Flash_V_Kernel_1.84.zip: directory
treewide: use deterministic-zip https://github.com/timo-reymann/deterministic-zip This solves a logistics issue; zip files always include the modified timestamp of a file. This doesn't sound bad until you realize that GitHub Actions always re-clones the entire repository, and the timestamp is guaranteed to be different. Because of this, every time we run our Actions workflow, the zip will have a different checksum, causing git to re-commit *every single file* to the frontend repository, causing long workflow times due to the sheer size of each commit. deterministic-zip hopefully solves this issue by forcing the modified timestamp to one hardcoded in its binary, so here is to hoping we don't abuse our git repo any further.
2024-01-15 06:59:35 +01:00
cd $(TOPDIR)/EZ-Flash_V_Kernel_1.84 && zip -r $(OUT)/$(BASE)/$@ *
EZ V (v1.80, v1.82, v1.83, v1.84, v1.86)
2023-08-12 23:45:38 +02:00
EZ-Flash_V_Kernel_1.86.zip: directory
treewide: use deterministic-zip https://github.com/timo-reymann/deterministic-zip This solves a logistics issue; zip files always include the modified timestamp of a file. This doesn't sound bad until you realize that GitHub Actions always re-clones the entire repository, and the timestamp is guaranteed to be different. Because of this, every time we run our Actions workflow, the zip will have a different checksum, causing git to re-commit *every single file* to the frontend repository, causing long workflow times due to the sheer size of each commit. deterministic-zip hopefully solves this issue by forcing the modified timestamp to one hardcoded in its binary, so here is to hoping we don't abuse our git repo any further.
2024-01-15 06:59:35 +01:00
cd $(TOPDIR)/EZ-Flash_V_Kernel_1.86 && zip -r $(OUT)/$(BASE)/$@ *
Reference in New Issue Copy Permalink