I just wanted to know what the process would be to install the OS after successfully compling locally? It seems we generate new images and then we need install to a usb and then re-install on our machine.
How do other Haiku devs handle their cycle of Code Change → Compile → Install?
I’m guessing most people use a VM to test it out thier newly built image V.S. updating their main OS. I currently run Haiku as my main OS and hoping to build my own Haiku kernel + apps and simply update in place (not sure if that is supported or not)
I was thinking if you had built Haiku locally, maybe I need to have seperate partitions:
for my data
for the OS (so then I could just write my new image to the usb and re-install to the OS partiton).
You probably want two OS partitions - one for a stable version of Haiku and one for your built version. That’s what i used to do, but now I just use a VM. If you update “in place” you have the risk of making a crashy unstable version. Of course you can always re-install a nightly to get back to working, but that is a pain. It’s easier to just have a stable partition and an unstable one in my opinion.
this only matters if you worry about data loss, in which case you should keep backups.
Haikus package manager works in a way that males this uneccesary, basically it reads a text file on boot about which packages to activate. but it also keeps all previous combinations so you can just go back in the bootloader if you installed a broken revision
I update my system similar to how X512 does it, only difference is that I build less packages overall (only haiku haiku_devel and haiku_datatranslators normally) and that I do it from a branch with patches for my system.
Different workflows are convenient for different setups.
Here are a few examples I use:
Porting to a new architecture
Work from an existing computer (Linux or Haiku). Generate images and run them in qemu or put them on SD card for testing on real hardware, or if you can, use network booting.
Writing a driver
There are two ways:
Work directly on the machine you are testing with. Build just that driver (using “jam -q xxx” where xxx is the driver name as defined in its Jamfile). Install the driver in the non-packaged directory, create appropriate symlinks in the driver directories, reboot to test. It is a bit annoying to have to leave your development session and reboot everytime you want to test.
Use network booting similar to the above. Generate a bootable image, and boot another computer on it. This way you can test on real hardware while keeping your development environment open
Working on an app
Build just the app you are modifying and start it manually. No need to build the whole OS.
For example:
jam -q WebPositive
to build just the web browser.
Working on system libraries
If you are modifying libbe for example.
Build just libbe:
jam -q libbe.so
Then for testing, put it next to an application in a directory tree that looks like this:
- SomeApp
- lib/
- libbe.so
Then you can run SomeApp from that executable. It will use your new lib instead of the system one.
Working on changes involving many parts or critical parts of the system
Maybe you have a change that involves both libbe and app_server, for example.
In that case, I have a second partition on my harddisk with a second Haiku install I use for testing.
I update it using:
jam -q @update
(this requires some setup in the build/jam/UserBuildConfig file to tell it where to install things). Then I reboot to that partition to test my changes. When using this, there is no need to recreate a whole image everytime, the changes are directly written to an existing BFS partition. You can even keep any extra packages and configuration you had installed there, which is very convenient (my test partition has some configuration and some extra packages installed for ease of debugging and investigating problems). You can also install just one package at a time (simply copy it to the /MyTestVolume/system/packages where MyTestVolume is the name and mountpoint of your test install).
Alternatively you can build some packages and install them to your running system as x512 proposes. However I prefer to use a separate system for testing and not risk breaking my main install (it depends what you work on, in most cases such breakages will not be so hard to recover as other people have mentioned).