PWD could be anything, if the user manually exported
it before running lbmk.
always run pwd instead, to get the real string.
Signed-off-by: Leah Rowe <leah@libreboot.org>
several code lines were condensed together, which
make them less readable. make the code more readable
by having separate commands on separate lines.
i previously did this during my manic build system
audits of 2023 and 2024; condensing lines like this
is overly pedantic and serves no real purpose.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The "mode" variable is used as a suffix for make commands,
for example ./mk -m sets mode to "menuconfig", which means
you want to run "make menuconfig".
When fetching sources (./mk -f), I was setting mode to "fetch",
and putting checks in code to avoid use of make when mode was
set to "fetch".
The behaviour now is identical, except that a new variable
called "do_make" is set to "n" when doing ./mk -f, otherwise
set to "y", and this is checked instead. This should make
the meaning of the code somewhat clearer.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we already check the python version, and set a variable
for it, so that we can reliably use python3, even if
python in PATH doesn't correspond to python3. for
example if a system has python as python2 and python3
as python3
well, we use that when running deguard for example, but
various upstream projects that we use may need python,
and all of them use python3, not 2
so, re-use the python variable set up by lbmk, and
set it up in PATH accordingly. this now makes the note
about python3 obsolete, on docs/build.md in lbwww.git
Signed-off-by: Leah Rowe <leah@libreboot.org>
it should fix more build errors that might have appeared
in the aforementioned revision, mentioned in the previous
commit message
Signed-off-by: Leah Rowe <leah@libreboot.org>
There was also a condition in run_make_command that is now
an OR, where it was an AND, on script/trees, to fix the use
of mixed (and erroneous) OR/AND operators.
I'm planning a much more invasive audit than this. These are
light fixes, intended for Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When doing ./mk release, the build system would create
symlinks inside xbmkpath/ relative to the current work tree,
which will differ from what's in PATH.
Since XBMK_CACHE is already set globally, from the main work
tree and the release-build work tree, that means we can know
reliably that PATH is always correct if we put xbmkpath/
inside XBMK_CACHE.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This reverts commit 7813205146.
I'm doing changes for 20241206 rev8. It was a mistake to
remove these; they will be removed again, after rev8.
The documentation standardised on ./mk a while ago now, and
it's almost time to remove these commands. However, anyone
using the old commands ought to be able to, up to and including
any revision of the Libreboot 20241206 release.
It is my intention that these legacy commands finally be
removed for the next testing release, as part of a much wider
build system audit that I'm doing between now and then.
(Libreboot Build System Audit 7 is underway, and several of
these early audit7 changes are going on 20241206 rev8; after
that, I will create a branch named 20241206_branch off of rev8,
and anything in master from then on will contain much wilder
changes, with more conservative changes in 20241206_branch)
Signed-off-by: Leah Rowe <leah@libreboot.org>
In general, we don't want to mess with the hostcc, unless
we have to. To avoid other breakage, clear what we did
after crossgcc has compiled.
This is a follow-up to the previous patches, matching gcc
to gnat versions and vice versa, when compiling crossgcc.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i intend for this function to work generically,
matching gnat to gcc or gcc to gnat, but there was
a hangover from the previous code where it specifically
assumed we were matching gnat
this bug manifested when i tested with gnat being v13
and gcc being v14 in path, where gcc-13 was also
available in path.
Signed-off-by: Leah Rowe <leah@libreboot.org>
on debian trixie/sid after updating from stable,
sometimes gcc 13 and gnat 13 are both available, but
gcc resolves to gcc-14 and gnat-14 isn't available.
even when gnat-14 and gcc-14 are available, gnat will
still either resolve to gnat-13, or nothing at all.
in cases where gnat-14 is unavailable, but gcc and gnat 13
are both available, we should match gcc to gnat.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When doing e.g. $@ we should use double quotes to prevent globbing.
Thanks go to XRevan86 for pointing this out.
Signed-off-by: Leah Rowe <leah@libreboot.org>
When I tested Debian Trixie, and Debian Sid, I saw that
GCC in PATH pointed to gcc-14, but gnat in path pointed
to GNAT-13, even if you manually install gnat-14.
GNAT 14 was marked experimental, but GCC 14 was marked
for use, in the apt repositories.
So this patch doesn't address the mismatch when doing e.g.
apt-get install gcc gnat
I will address the actual package dependency in a follow-up
patch, on the Debian dependencies config.
Signed-off-by: Leah Rowe <leah@libreboot.org>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.
To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.
In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.
It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!
Anyway, the variable in target.cfg is:
cleancmd="whatever_you_want"
e.g.
cleancmd="distclean"
You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Otherwise, if PATH was set before, it will be re-used
again in the next pass. We previously unset CROSS_COMPILE
to avoid using the wrong cross-compiler when switching to
another target within a multi-tree project such as U-Boot.
Well, PATH was also being set, to use coreboot xgcc first.
This is fine, but the next target may not use the same one.
This patch solves a similar problem to the following patch
which was mentioned above:
commit 637c0a1521
Author: Leah Rowe <leah@libreboot.org>
Date: Tue Nov 19 02:52:28 2024 +0000
trees: unset CROSS_COMPILE per target
Signed-off-by: Leah Rowe <leah@libreboot.org>
When building a coreboot image, if they enable the
x86 U-Boot payloads, sometimes what happens is you
have CROSS_COMPILE set, for i386-elf, but then it's
still set to that when later building 64-bit U-Boot,
which needs x86_64-elf.
We currently rely on hostcc to build U-Boot.
To mitigate this, unset CROSS_COMPILE in the main
loop of the trees script, for building project targets.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Remove what is now unnecessary bloat, for ensuring that
GRUB is the primary payload; SeaGRUB is the only preference,
as per lbmk design.
The SeaBIOS hanging issue was fixed, so SeaGRUB is OK now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
SeaBIOS is known to hang on this board. It is being investigated.
Add two variable options for target.cfg files:
* seabiosname
* grubname
This string defines where it would be located in CBFS.
Signed-off-by: Leah Rowe <leah@libreboot.org>
I also added a "cleanargs" argument, similar to the makeargs
argument, to work around a build error.
This builds the PCSX-Redux PS1 BIOS. They reverse engineered
the Sony PS1 BIOS and wrote a free one under MIT license.
Run this:
./mk -b pcsx-redux
The file will appear: bin/playstation/openbios.bin
Signed-off-by: Leah Rowe <leah@libreboot.org>
single-tree projects cannot be handled in bulk, e.g.
./mk -f project1 project2 project3
that is still the case, from the shell, but internally
it is now possible:
mk -f project1 project2 project3
mk() is a function that simply handles the given flag,
and all projects specified.
it does not handle cases without argument, for example
you cannot do:
mk -f
arguments must be provided. it can be used internally,
to simplify cases where multiple single-tree projects
must be handled, but *also* allows multi-tree projects
to be specified, without being able to actually handle
trees within that multi-tree project; so for example,
you can only specify coreboot, and then it would run
on every coreboot tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is another alternative to the previous fix. this one
is therefore now a pre-emptive fix, in case other code is
written in the future that makes use of badhash.
the badhash variable in a y/n variable, so initialise to n.
Signed-off-by: Leah Rowe <leah@libreboot.org>
XBMK_CACHE is now used, instead of hardcoding cache/
this is exported initialised to cache/, if unset.
this means you can set your own directory, and it means
./update release will use the same directory.
this means bandwidth wastage is further avoided.
Signed-off-by: Leah Rowe <leah@libreboot.org>
if coreboot itself is being handled, crossgcc has the
correct makeargs, setting the number of build threads.
however, other projects can specify "xtree" pointing to
a given coreboot tree, and build crossgcc for it.
one workaround may be to use trees -d coreboot TREE,
but then extra code would have to be written to make
it avoid other things like building cbfstool, which is
not required for just building crossgcc.
the cleanest way to do it is to simply hardcode it. the
value is set exactly the same as regular coreboot makeargs.
this fixes a bug, where some builds of crossgcc are made
on a single thread, rather than using XBMK_THREADS. this
patch forces it to always use CPUS=$XBMK_THREADS
Signed-off-by: Leah Rowe <leah@libreboot.org>
we no longer need to remove cache/ per project, because
it's removed in bulk at the end, in the main build script,
when generating release archives.
Signed-off-by: Leah Rowe <leah@libreboot.org>
actual source code is not scanned, but config directories are
scanned. simply get the checksum of each file under config/
pertaining to a given project/tree, and also for the given
target. coreboot utilities are also handled.
if it changes, in any way, delete and re-build automatically.
such deletions should probably still be done manually, as part
of understanding the build system, but this change should make
the build system much easier to use during development.
Signed-off-by: Leah Rowe <leah@libreboot.org>
single-tree repos were not previously cached, but now
they are and they have to be handled.
this, as also alluded to in the previous commit, is done
when preparing release archives (XBMK_RELEASE=y)
Signed-off-by: Leah Rowe <leah@libreboot.org>
repo/p/ does not have its revision reset, so it
changes unpredictably, and it's not used in builds.
this used to be src/p/p/ - the context here is multi-tree
projects, in source archives.
Signed-off-by: Leah Rowe <leah@libreboot.org>
upstream has merged all of the changes that it contained,
so we don't need this anymore. we'll have the newer upstream
changes on the next general revision updates for coreboot,
within config/coreboot/
Signed-off-by: Leah Rowe <leah@libreboot.org>
configure_project is a bit big. move the dependencies
build logic to a new function.
it may be desirable in future to make the way that
function works the way all build commands are done.
for example:
./update trees -b coreboot x230_12mb
would become:
./update trees -b coreboot/x230_12mb
this would enable to mix and match multi/single tree
projects. for now, leave things as they are.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we used to set cmd only to these values:
build_project
build_targets
however, now we set them to:
build_project
build_targets $@
the latter cannot be measured reliably, but
we were checking whether cmd equalled:
build_targets
now we instead check that it does not equal:
build_project
Signed-off-by: Leah Rowe <leah@libreboot.org>
main() used to be the only function executed from
outside of main(), in this script, but now we source
a config file and then run the build afterward.
when a flag is provided without OPTARG, this means
that we are continuing such action erroneously. to
mitigate this, return 1 in that instance, and handle
it in the line that calls main(), making it exit with
zero status (success).
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead of using lots of if/else conditions, do that once
and set a variable, dry, to :
if not doing a dry run, the variable is empty. prefix this
variable in places where you don't want a certain action to
be performed, on dry runs.
more specifically, : does *nothing* and always returns with
zero status (success).
this results in cleaner code, and a small sloccount reduction.
Signed-off-by: Leah Rowe <leah@libreboot.org>
