So what is it that you want to change that the current images don't
provide?
In hindsight, I found out there's already a qcow2 image and the only
thing left to do would be a Vagrant configuration that used that image.
You may want to use a standard iso image to install FreeBSD
into a virtual machine and then do your modified build within that and
install over the standard system install.
This is not for a modified build actually, it's for automated tests.
So I don't need to do the build, except I wanted to study it to know
where to insert the Vagrant configuration - I can't send a patch unless
I know it builds cleanly, can I?
I know it's probably possible to take shortcuts here, if the Vagrant
configs are created during "make release", but I don't now enough about
FreeBSD's build system to confidently do that, and I ultimately stopped
the effort when the cross-build setup failed.
https://computingforgeeks.com/how-to-install-freebsd-on-kvm-virtualbox/
Good to know there's a ready-made set of instructions for interactive
setup. Some KVM parameters aren't easy to understand, and would have
required experimentation.
It's based on an interactive tool, so I'll need to replace that with
scripting for automated testing, and it's using an install image so
there's a lot of interactive steps, but I found the for-VM images,
including a qcow2 one, so I can whip something up I believe.
I won't be able to use Vagrant, and I won't have the expectation that
this specific kind of image will be available in future releases, but I
guess there are no guarantees for that kind of stuff anyway.
You can also find a list of pre-built virtual disk images at the bottom
of the release announcement.
https://www.freebsd.org/releases/14.0R/announce/
I found the images directly :-)
Onwards to the next question:
What would be the right place to ask questions about how to run `make`?
In case this is already the right place, here they are:
1) I'm worried that make will write files to directories that I'm not
aware of, or even overwrite stuff it has no business overwriting.
How to I make sure that it does not write anywhere except
~/projects/freebsd (which is the place where I want to experiment with
the freebsd build)?
Running make buildworld will keep all build output within MAKEOBJDIRPREFIX
I figured that much, but it's good to have a confirmation from somebody
with more experience.
3) I need to run make on a Linux box.
Aahh, so you are trying to cross compile FreeBSD on Linux. Seems this
should be easier than in the past, have you looked at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#building-on-non-freebsd-hosts
Yeah, it fails on today's Debian.
Autodetection does not find clang's cpp, possibly due to a quirk in
Debian's clang setup, and even getting to that point was a lot of
experimentation.
I stopped trying that approach, since it was too much of "with each
hurdle passed, another one comes up", which Isn't Worth It(tm) if
there's an alternative approach available.
It is a few years old, but this creates a docker image to build FreeBSD
https://github.com/sandvine/freebsd-cross-build
That's for building FreeBSD inside a Docker container.
It does some interesting things:
- Download the gcc toolchain (at a specific version).
- Configure it with some very specific option and build it.
- Prepare things so the toolchain will be picked up by make.py.
It does not start the actual build, which would (hopefully) be "just
call make.py, the environment is already set up for this".
I don't know why it uses a Docker container. One reason might be to
allow doing the build on Windows, another one might be to isolate the
build from the host to avoid any risk of environment pollution.
It's using the gcc toolchain instead of clang, and I don't know of any
justification for that, except maybe for better toolchain knowledge.
Still, it's a useful baseline for those who want to run a build in a
Docker contains.
Regards,
Jo