You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make it possible to enable/disable features when building. Alos thinking about adding some kind of optional patches support. Ex: put files in a patches directory and then will be applied in sorted order. Maybe patches/$FEATURE/001-fix.patch?
I think an ideal usage would be something like this:
# as before, all features enabled
docker build .# all except rav1e
docker build --build-arg FEATURES="-rav1e".# no features at all
docker build --build-arg FEATURES="-all".# only libfdk-aac
docker build --build-arg FEATURES="-all +libfdk-aac".
Issues to think about:
Build cache (one RUN running a big shell script can not use cache)
Feature dependencies (libogg needed by libvorbis etc)
How to keep it simple. I currently like that it is just a very standard Dockerfile without many moving parts of big helper scripts
Would be nice if all things for a feature could be kept together. Currently verison, build instructions is separate from ffmpeg args
Possibly could use heredoc but maybe a too new feature
Normalize feature names. vorbis -> libvorbis etc? use what ffmpeg calls it?
Possible implementation combining simple Dockerfile, cache friendly and no big shell script:
ARG FEATURES
# embed or COPY scripts for enable/enabled/download etc# enable all dependencies and eval $FEATURESRUN enabled \
fontconfig \
gray \
... \
$FEATURES
...
# handle dependenciesRUN \
enabled vorbis && enable ogg; \
...
...
libogg build here
...
# bump: vorbis /VORBIS_VERSION=([\d.]+)/ https://github.com/xiph/vorbis.git|*# bump: vorbis after ./hashupdate Dockerfile VORBIS $LATEST# bump: vorbis link "CHANGES" https://github.com/xiph/vorbis/blob/master/CHANGES# bump: vorbis link "Source diff $CURRENT..$LATEST" https://github.com/xiph/vorbis/compare/v$CURRENT..v$LATESTARG VORBIS_VERSION=1.3.7
ARG VORBIS_URL="https://downloads.xiph.org/releases/vorbis/libvorbis-$VORBIS_VERSION.tar.gz"ARG VORBIS_SHA256=0e982409a9c3fc82ee06e08205b1355e5c6aa4c36bca58146ef399621b0ce5ab
RUN if enabled vorbis; then \
download $DAV1D_URL $DAV1D_SHA256 && \
add-version vorbis $VORBIS_VERSION && \
ffmpeg-configure --enable-libvorbis && \
cd libvorbis-* && ./configure --disable-shared --enable-static --disable-oggtest && \
make -j$(nproc) install \
fi
A simple way to implement enable/enabled is to just use files in a directory, so enable would for +?name do touch /featurs/$1, for -name do rm /featurs/$1 and for -all do rm /features/*. add-version could just append to a JSON file. ffmpeg-configure just append to a file and download wrapper around wget and checksum check.
The text was updated successfully, but these errors were encountered:
Make it possible to enable/disable features when building. Alos thinking about adding some kind of optional patches support. Ex: put files in a
patches
directory and then will be applied in sorted order. Maybepatches/$FEATURE/001-fix.patch
?I think an ideal usage would be something like this:
Issues to think about:
RUN
running a big shell script can not use cache)Possible implementation combining simple Dockerfile, cache friendly and no big shell script:
A simple way to implement enable/enabled is to just use files in a directory, so
enable
would for+?name
dotouch /featurs/$1
, for-name
dorm /featurs/$1
and for-all
dorm /features/*
.add-version
could just append to a JSON file.ffmpeg-configure
just append to a file anddownload
wrapper around wget and checksum check.The text was updated successfully, but these errors were encountered: