2014-12-26 02:11:19 +01:00
|
|
|
PYLINT_OPTS = --report=no -d I -d C -d R -d W0511
|
|
|
|
|
2013-03-23 16:30:19 +01:00
|
|
|
all: svtplay-dl
|
|
|
|
|
|
|
|
clean:
|
2013-08-10 20:50:52 +02:00
|
|
|
find . -name '*.pyc' -exec rm {} \;
|
2013-03-23 16:30:19 +01:00
|
|
|
rm -f svtplay-dl
|
|
|
|
|
2014-12-26 02:11:19 +01:00
|
|
|
pylint:
|
|
|
|
pylint $(PYLINT_OPTS) svtplay_dl
|
|
|
|
|
2013-04-21 14:08:41 +02:00
|
|
|
export PACKAGES = svtplay_dl \
|
|
|
|
svtplay_dl.fetcher \
|
|
|
|
svtplay_dl.utils \
|
2014-06-14 14:38:21 +02:00
|
|
|
svtplay_dl.service \
|
|
|
|
svtplay_dl.subtitle
|
build: Truncate timestamps in zip archive
Even though zip's -X flag suggests that it removes timestamps, that's not
quite true. There's still modification times per file, and that introduces
non-determinism that are hard to notice, since the mtimes are unlikely to
change without changes to the files. Only when doing a new clone/unpacking
a tar ball under some circumstances or similar action that resets/discards
the mtimes, we would notice.
So, the -X is not enough, and from what I can tell, there's no way of
telling zip to not include timestamps (or truncate them). With this
change, we stage all files in a temporary .build directory, and set the
mtime manually to the beginning of time (as is the case for zip files:
1980-01-01T00:00). These timestamps should not be important to anyone,
since they are all presented to the user as a blob.
The rationale for this change is that this makes it possible to build
svtplay-dl reproducibly. And it also removes the pesky svtplay-dl diffs
just from regenerating the executable.
2015-05-30 01:54:55 +02:00
|
|
|
export PYFILES = $(sort $(addsuffix /*.py,$(subst .,/,$(PACKAGES))))
|
2013-04-21 14:08:41 +02:00
|
|
|
|
2014-02-02 15:10:17 +01:00
|
|
|
PYTHON ?= /usr/bin/env python
|
2013-03-23 16:30:19 +01:00
|
|
|
|
2013-04-21 14:08:41 +02:00
|
|
|
svtplay-dl: $(PYFILES)
|
build: Truncate timestamps in zip archive
Even though zip's -X flag suggests that it removes timestamps, that's not
quite true. There's still modification times per file, and that introduces
non-determinism that are hard to notice, since the mtimes are unlikely to
change without changes to the files. Only when doing a new clone/unpacking
a tar ball under some circumstances or similar action that resets/discards
the mtimes, we would notice.
So, the -X is not enough, and from what I can tell, there's no way of
telling zip to not include timestamps (or truncate them). With this
change, we stage all files in a temporary .build directory, and set the
mtime manually to the beginning of time (as is the case for zip files:
1980-01-01T00:00). These timestamps should not be important to anyone,
since they are all presented to the user as a blob.
The rationale for this change is that this makes it possible to build
svtplay-dl reproducibly. And it also removes the pesky svtplay-dl diffs
just from regenerating the executable.
2015-05-30 01:54:55 +02:00
|
|
|
@# Verify that there's no .build already \
|
|
|
|
! [ -d .build ] || { \
|
|
|
|
echo "ERROR: build already in progress? (or remove $(PWD)/.build/)"; \
|
|
|
|
exit 1; \
|
|
|
|
}; \
|
|
|
|
mkdir -p .build
|
|
|
|
|
|
|
|
@# Stage the files in .build for postprocessing
|
|
|
|
for py in $(PYFILES); do install -D $$py .build/$$py; done
|
|
|
|
|
|
|
|
@# reset timestamps, to avoid non-determinism in zip file
|
|
|
|
find .build/ -exec touch -m -t 198001010000 {} \;
|
|
|
|
|
|
|
|
(cd .build && zip -X --quiet svtplay-dl $(PYFILES))
|
|
|
|
(cd .build && zip -X --quiet --junk-paths svtplay-dl svtplay_dl/__main__.py)
|
|
|
|
|
2013-03-23 16:30:19 +01:00
|
|
|
echo '#!$(PYTHON)' > svtplay-dl
|
build: Truncate timestamps in zip archive
Even though zip's -X flag suggests that it removes timestamps, that's not
quite true. There's still modification times per file, and that introduces
non-determinism that are hard to notice, since the mtimes are unlikely to
change without changes to the files. Only when doing a new clone/unpacking
a tar ball under some circumstances or similar action that resets/discards
the mtimes, we would notice.
So, the -X is not enough, and from what I can tell, there's no way of
telling zip to not include timestamps (or truncate them). With this
change, we stage all files in a temporary .build directory, and set the
mtime manually to the beginning of time (as is the case for zip files:
1980-01-01T00:00). These timestamps should not be important to anyone,
since they are all presented to the user as a blob.
The rationale for this change is that this makes it possible to build
svtplay-dl reproducibly. And it also removes the pesky svtplay-dl diffs
just from regenerating the executable.
2015-05-30 01:54:55 +02:00
|
|
|
cat .build/svtplay-dl.zip >> svtplay-dl
|
|
|
|
rm -rf .build
|
2013-03-23 16:30:19 +01:00
|
|
|
chmod a+x svtplay-dl
|