Closed ashthespy closed 3 years ago
Similarly, MOUNT_DIR seems to be something where the user may wish to override.
I think it would be useful for BUILD_OUTPUT_DIR to appear in config.sh, even if only in a comment so that someone coming to this could see that this location can be customized. Or, perhaps in build.sh give a list the variables you are expecting the user may wish to override.
There are bunch of such flags that I should document. 😧
Personally I don't see a point in putting them in config.sh
as flags there impact the final image, whereas these are more flags for the build system itself.
I normally have a wrapper that calls build.sh
inside a docker environment, so there is where I add all the flags.
Something along these lines..
#!/usr/bin/env bash
set -eo pipefail
build_name=Build_$(date +%Y-%m-%d_%H-%M-%S)
mkdir -p "${build_name}"
#TODO: Document these for others!
# Some Build configuration flags -- usually enough to set non default values to reduce clutter.
# Working directories
# export BUILD_OUTPUT_DIR=./build # dir for rootfs creation
# export MOUNT_DIR=/mnt/volumio # dir where rootfs is mounted to create final image
# export LOCAL_PKG_DIR # location of locally built packages
# export LOCAL_MODULES_DIR # same for node_modules tarball
<snip>
# Misc
export USE_BUILD_TESTS=no # Run some simple build framework tests on troublesome packages
export USE_EXTRA_REPOS=yes # Use Debian updates and security repos
# export APT_CACHE # URL of local cache of the Debian mirror
What do you think?
Personally feel that build system flags should be documented in the Readme/Wiki -- as this are something only "advanced" users are expected to be playing with..
On second thought, we could always add another buildoptions.sh
or something along those lines and use that as a central place for setting these flags and associated default values. External wrappers can always override them as they please.
@xipmix Would be great if you could give this a whirl with your current setup as a quick counter check :-)
Merging into vOS/dev
for now, can be merged into volumioOS
at a later stage..
Cherry picked and synced up some stuff from my personal branch.. The refactor is largely a transparent rename, instead of having everything under
volumio
While in there, I found some inconsistencies with the
ext3/4
labels in themkpart
call, so that is also fixed.The rest are small "quality of life" changes, you can set some variables to configure where the
rootfs
is built, and where the working mount directory is.PS: these are just changes to the build system, and should not effect the final images being built..