note: mecleaner check removed in vendor.sh, because
it's already guaranteed to be fetched. the check will
never indicate failure, so we can just assume that
the me cleaner python script exists.
Signed-off-by: Leah Rowe <leah@libreboot.org>
ccache isn't used at all in any of the configs
ensuring that this remains the case is much
cleaner. coreboot will never enable it by default,
precisely because of how buggy it is.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the modified/not message is pointless, because the
message indicating tarball rebuild will suffice
variable initialisation simplified (global newvar)
Signed-off-by: Leah Rowe <leah@libreboot.org>
-m src can skip building binaries
this is pointless. i always want them.
i won't use it, and i'm the only person
who will ever use ./mk release
i'm going to add a -t option in the future
to allow e.g. ./mk -t coreboot
this would do -f but create a tarball of
the source, versioned. e.g.
coreboot-libreboot-27.05_src.tar.xz
or something like that. this would allow
more granular control, if you just want to
get sources.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this fixes a build issue i was having on ./mk release,
and it's also a preventative bug fix.
instead of forcing it to be enabled, we now force
it to be disabled. all current configs already disable
it, and disabled is the default.
just in case, disable it by force. i encountered build
errors on ./mk release, due to stale build artifacts.
i had no issues on normal lbmk.git, doing builds, but
./mk release builds everything in bulk. we want the
release build process to be as reliable as possible.
this won't actually affect build speed much, due to
lbmk's design (clean builds before running make).
work is needed upstream, to make ccache more reliable.
ccache is fine when you're re-building the same board
a lot, but there's just no way it can be used reliably
when building lots of very different boards, where the
code greatly differs in coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
when calling ./mk, or from PATH, an absolute path
is created to ./mk
this will likely be different than mk, but it might
be a different script. perhaps the operator is making
a copy of the mk script temporarily - obviously not
advised, no, but here we have a problem because then
lbmk is still running ./mk everywhere
run arg0 instead, now called "mk"
./mk is still hardcoded in release.sh, because we
do need to make sure we're using the right script
there
Signed-off-by: Leah Rowe <leah@libreboot.org>
e.g. biosutilities
the subshell screws up error handling. this
patch changes it to old behaviour.
some projects don't have makefiles. the
non-zero exit also prevents further call
to copy_elf when no binaries are created,
as in this example.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit cf079dbd17.
we don't need it anymore. we don't bother cleaning sources
for releases, because tehy're never dirtied. we build
using ./mk release which does everything fresh.
the git-clean feature was only used on ./mk -c, which was
removed because it's not needed for the same reason as
above. lbmk always cleans and re-builds everything when
metadata changes, otherwise storing builds out of tree
in a cache directory.
get rid of this dead code.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the user never runs these. it's not needed. the design
of lbmk already cleans everything, or caches everything,
between builds. everything cached out of tree.
it's not expected to ever need to clean manually, so just
remove the option. knobs are for nobs.
releases don't need it either, because we tar everything
before building, thus eliminating all build artifacts.
we do this on a fresh copy of lbmk on ./mk release
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was the previous behaviour, and prevents
single-tree builds from proceeding with
use of copy_elf
otherwise you get a bunch of build errors
Signed-off-by: Leah Rowe <leah@libreboot.org>
no point using distclean, because the context there
is providing clean sources for distribution, but we
use ./mk release which tars everything up before ever
running any build commands.
make-clean is enough
distclean is a stupid gnuism anyway, and most makefiles
that have it will just do the same as clean anyway
Signed-off-by: Leah Rowe <leah@libreboot.org>
we have git-clean in use for projects, but that
only affects lbmk.git
now we re-initialise .git in upstream projects,
when .git is missing. this ensures consistent
cleaning behaviour between lbmk.git and the
libreboot releases.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in practise, it was always correct because on projects
that used coreboot xgcc, the tree would always be called
default.
however, this is a bug. the logic uses a correct directory
name for coreboot in src/, but not elf/
this patch makes the two consistent, programattically.
this is therefore a preventative bugfix.
Signed-off-by: Leah Rowe <leah@libreboot.org>
libreboot's policy is to thoroughly clean sources per
build, because we cache builds out of tree and avoid
re-builds if they exist; these and the sources are
deleted if metadata in config/ changes per project,
tree and/or target.
the problem is that this change only affects lbmk.git
it doesn't affect release archives, where project sources
do not have git-init applied to them. this will be
addressed.
can't use it on coreboot, because it will delete xgcc
tarballs in a way currently not handled, and handling
it will mean adding a project-specific hack.
the xgcc tarballs could be built out-of-tree, and this
will have to be done, otherwise coreboot will have to be
made gitclean="y" for now.
everything else is fair game.
Signed-off-by: Leah Rowe <leah@libreboot.org>
yes, make it generalised. use a new variable in
mkhelper.cfg, gitclean and gitcleanargs
not enabled by default, but u-boot enables it. i'm
considering whether to use this by default, as it
is the general policy of lbmk to clean everything
just after a build, as builds are cached out of
tree. this way, we can do re-builds safely for each
project. there are probably a lot of subtle bugs that
might be fixed if we used this
the problem is that this is currently only used on
lbmk.git, but not on libreboot release archives which
lack .git directories; the main one is initialised in
lbmk, but not in upstream sources. we could just initialise
those.
in fact, that is probably what i'm going to do.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe