TL; DR: A newbie saw Haiku for the first time, trying to port some programs from the Linux world.
My first Haiku port packaged in its hpkg format
I discovered Haiku, an unexpectedly good PC operating system.
Today I will learn how to transfer new programs to this operating system. The main focus is describing the first experience of moving to Haiku from the point of view of a Linux developer. I apologize for any stupid mistakes I made along the way, it hasn't even been a week since I first uploaded Haiku.
I want to achieve three goals:
- Port a simple CLI application
- Port GUI application to Qt
- Pack them later in hpkg format (because I'm still thinking about adapting AppDir and AppImage for Haiku...)
Let's get started. Sections ΠΈ , and so in from HaikuPorts I found the right direction. There is even an online PDF book .
467 pages - and this is from 1997! Looking inside is scary, but I hope for the best. The words of the developer are encouraging: βfor a long time, because BeOS was not POSIX-compliantβ, but Haiku βfor the most partβ already is.
Porting a simple CLI application
The first thought was to port the application , but as it turned out, this a long time ago.
First try: nothing to watch
What I don't understand at all is that - despite the fact that the OS itself is not even version 1.0 yet.
Second attempt: need to rewrite
So I will use , CLI to control the Brother P-Touch 770 printer I print labels on.
I print various labels on it, and you may have already seen it in the last article. A little earlier, I wrote a small wrapper program with a GUI in Python (since it is in Gtk +, I will have to rewrite it, and this is a good reason to learn).
Printer for labels Brother P-Touch 770. Will it work under Haiku?
The Haiku package manager knows about libraries and commands, so if I get a "can't find libintl" message when I run configure - just start pkgman install devel:libintl and the required package will be found. Similarly pkgman install cmd:rsync. Well, etc.
Except when this doesn't work:
/Haiku/home> git clone https://github.com/probonopd/ptouch-770
Cloning into 'ptouch-770'...
remote: Enumerating objects: 134, done.
remote: Total 134 (delta 0), reused 0 (delta 0), pack-reused 134
Receiving objects: 100% (134/134), 98.91 KiB | 637.00 KiB/s, done.
Resolving deltas: 100% (71/71), done./Haiku/home> cd ptouch-770//Haiku/home/ptouch-770> make
gcc -Wall -O2 -c -o ptouch-770-write.o ptouch-770-write.c
ptouch-770-write.c:28:10: fatal error: libudev.h: No such file or directory
#include <libudev.h>
^~~~~~~~~~~
compilation terminated.
Makefile:16: recipe for target 'ptouch-770-write.o' failed
make: *** [ptouch-770-write.o] Error 1/Haiku/home/ptouch-770> pkgman install devel:libudev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:libudev": Name not found/Haiku/home/ptouch-770> pkgman install devel:udev
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:udev": Name not foundMaybe udev is too linux so it doesn't exist for Haiku. Which means I need to edit the source code I'm trying to compile.
Eh, you canβt jump above your head, and I donβt even know where to start.
Third attempt
It would be nice to have tmate for Haiku, then I would allow Haiku developers to connect to my terminal session in case something goes wrong. The instructions are quite simple:
./autogen.sh
./configure
make
make installLooks good, so why not try it on Haiku?
/Haiku/home> git clone https://github.com/tmate-io/tmate/Haiku/home> cd tmate//Haiku/home/tmate> ./autogen.sh
(...)/Haiku/home/tmate> ./configure
(...)
checking for libevent... no
checking for library containing event_init... no
configure: error: "libevent not found"/Haiku/home/tmate> pkgman install devel:libevent
(...)
The following changes will be made:
in system:
install package libevent21-2.1.8-2 from repository HaikuPorts
install package libevent21_devel-2.1.8-2 from repository HaikuPorts
Continue? [yes/no] (yes) :
100% libevent21-2.1.8-2-x86_64.hpkg [965.22 KiB]
(...)
[system] Done.checking for ncurses... no
checking for library containing setupterm... no
configure: error: "curses not found"/Haiku/home/tmate> pkgman install devel:libcurses
(...)
*** Failed to find a match for "devel:libcurses": Name not found/Haiku/home/tmate> pkgman install devel:curses
(...)
*** Failed to find a match for "devel:curses": Name not foundIn this step, I open HaikuDepot and look for curses.
Something was found, which gave me a hint for a more competent query:
/Haiku/home/tmate> pkgman install devel:libncurses
(...)
100% ncurses6_devel-6.1-1-x86_64.hpkg [835.62 KiB]
(...)./configure
(...)
checking for msgpack >= 1.1.0... no
configure: error: "msgpack >= 1.1.0 not found"/Haiku/home/tmate> pkgman install devel:msgpack
(...)
*** Failed to find a match for "devel:msgpack": Name not found/Haiku/home/tmate> pkgman install devel:libmsgpack
(...)
*** Failed to find a match for "devel:libmsgpack": Name not foundAgain I went to HaikuDepot, and, of course, I found devel:msgpack_c_cpp_devel. What strange names?
/Haiku/home/tmate> pkgman install devel:msgpack_c_cpp_devel
100% repochecksum-1 [65 bytes]
Validating checksum for Haiku...done.
100% repochecksum-1 [64 bytes]
Validating checksum for HaikuPorts...done.
*** Failed to find a match for "devel:msgpack_c_cpp_devel": Name not found# Why is it not finding it? To hell with the "devel:".../Haiku/home/tmate> pkgman install msgpack_c_cpp_devel
(...)
The following changes will be made:
in system:
install package msgpack_c_cpp-3.1.1-1 from repository HaikuPorts
install package msgpack_c_cpp_devel-3.1.1-1 from repository HaikuPorts
Continue? [yes/no] (yes) :
(...)/Haiku/home/tmate> ./configure
(...)
checking for libssh >= 0.8.4... no
configure: error: "libssh >= 0.8.4 not found"/Haiku/home/tmate> pkgman install devel:libssh/Haiku/home/tmate> make
(...)
In file included from /boot/system/develop/headers/msgpack.h:22,
from tmate.h:5,
from cfg.c:29:
/boot/system/develop/headers/msgpack/vrefbuffer.h:19:8: error: redefinition of struct iovec'
struct iovec {
^~~~~
In file included from tmux.h:27,
from cfg.c:28:
/boot/system/develop/headers/posix/sys/uio.h:12:16: note: originally defined here
typedef struct iovec {
^~~~~
Makefile:969: recipe for target 'cfg.o' failed
make: *** [cfg.o] Error 1At this point, I realized that porting a program to Haiku requires much more knowledge than a simple rebuild would require.
I talked to the friendly Haiku developers, it turned out that there is a bug in msgpack, and after a few minutes I see a patch in HaikuPorts. I see firsthand how the corrected package (buildslave - virtual machines).
Building fixed msgpack on buildmaster
In the meantime, I send a patch to upstream .
Five minutes later, the updated msgpack is already available on Haiku:
/Haiku/home/tmate> pkgman update
(...)
The following changes will be made:
in system:
upgrade package msgpack_c_cpp-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
upgrade package msgpack_c_cpp_devel-3.1.1-1 to 3.2.0-2 from repository HaikuPorts
Continue? [yes/no] (yes) : y
100% msgpack_c_cpp-3.2.0-2-x86_64.hpkg [13.43 KiB]
(...)
[system] Done.Unexpectedly good. Is that what I said?!
Going back to the original problem:
/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
from tty.c:32:
compat.h:266: warning: "AT_FDCWD" redefined
#define AT_FDCWD -100
In file included from tty.c:25:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
#define AT_FDCWD (-1) /* CWD FD for the *at() functions */
tty.c: In function 'tty_init_termios':
tty.c:278:48: error: 'IMAXBEL' undeclared (first use in this function); did you mean 'MAXLABEL'?
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|IMAXBEL|ISTRIP);
^~~~~~~
MAXLABEL
tty.c:278:48: note: each undeclared identifier is reported only once for each function it appears in
Makefile:969: recipe for target 'tty.o' failed
make: *** [tty.o] Error 1Right now it looks like msgpack is not at fault. commenting IMAXLABEL Π² tty.c as follows:
tio.c_iflag &= ~(IXON|IXOFF|ICRNL|INLCR|IGNCR|/*IMAXBEL|*/ISTRIP);Result:
osdep-unknown.c: In function 'osdep_get_cwd':
osdep-unknown.c:32:19: warning: unused parameter 'fd' [-Wunused-parameter]
osdep_get_cwd(int fd)
~~~~^~
make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.Well, again ... By the way:
/Haiku/home/tmate> ./configure | grep -i OPENAT
checking for openat... notells you where to dig:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
In file included from tmux.h:40,
from window.c:31:
compat.h:266: warning: "AT_FDCWD" redefined
#define AT_FDCWD -100
In file included from window.c:22:
/boot/system/develop/headers/posix/fcntl.h:62: note: this is the location of the previous definition
#define AT_FDCWD (-1) /* CWD FD for the *at() functions */
make: *** No rule to make target 'compat/forkpty-unknown.c', needed by 'compat/forkpty-unknown.o'. Stop.Here I posted .
I was told that there is something else for libresolv on Haiku in libnetwork. It looks like the code needs to be improved further. Need to thinkβ¦
find . -type f -exec sed -i -e 's|lresolv|lnetwork|g' {} ;The eternal question: what is going on.
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd"
(...)/Haiku/home/tmate> make
(...)
# Success!# Let's run it:/Haiku/home/tmate> ./tmate
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Could not resolve symbol '__stack_chk_guard'
resolve symbol "__stack_chk_guard" returned: -2147478780
runtime_loader: /boot/system/lib/libssh.so.4.7.2: Troubles relocating: Symbol not foundThe same, only in profile. Googled and . If add -lssp "sometimes" helps, I try:
/Haiku/home/tmate> ./configure LDFLAGS="-lbsd -lssp"
(...)/Haiku/home/tmate> make
(...)/Haiku/home/tmate> ./tmateWow! It's starting! Butβ¦
[tmate] ssh.tmate.io lookup failure. Retrying in 2 seconds (non-recoverable failure in name resolution)I'll try to debug :
/Haiku/home/tmate> strace -f ./tmate >log 2>&1"Bad port ID" is already like a business card . Can anyone imagine what is wrong and how to fix it? If so, I'll update the article. Link to .
Porting a GUI application to Qt.
I choose a simple QML application.
/> cd /Haiku/home//Haiku/home> git clone https://github.com/probonopd/QtQuickApp
/Haiku/home/QtQuickApp> qmake .
/Haiku/home/QtQuickApp> make
/Haiku/home/QtQuickApp> ./QtQuickApp # Works!Really simple. Less than a minute!
Packaging applications in hpkg using haikuporter and haikuports.
What should I start with? There is no simple documentation, so I go to the #haiku channel on irc.freenode.net and hear:
- Team
packageis a low-level way to create packages. For the most part, the PackageInfo is sufficient, as described in "Making it into a proper .hpkg package" - I need to do something
- Can be used (it crashes for me, )
It's not clear what to do. I guess I need a "Hello World" style guide for beginners, ideally a video. It would also be nice to have a handy introduction to HaikuPorter, as done in GNU hello.
I am reading the following:
haikuporteris a tool for creating generic package projects for Haiku. It uses the HaikuPorts repository as the base for all packages. Haikuporter recipes are used to create packages.
Additionally, I know that:
There is no need to keep recipes in the HaikuPorts repository. You can make another repository, put recipes in it, and then point haikuporter to it.
Just what I need - if not looking for a way to publicly host the package. But that's a topic for another post.
Installing haikuporter and haikuports
cd /boot/home/
git clone https://github.com/haikuports/haikuporter --depth=50
git clone https://github.com/haikuports/haikuports --depth=50
ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/ # make it runnable from anywhere
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf
sed -i -e 's|/mydisk/haikuports|/boot/home/haikuports|g' /boot/home/config/settings/haikuports.confWriting a recipe
SUMMARY="Demo QtQuick application"
DESCRIPTION="QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"
HOMEPAGE="https://github.com/probonopd/QtQuickApp"
COPYRIGHT="None"
LICENSE="MIT"
REVISION="1"
SOURCE_URI="https://github.com/probonopd/QtQuickApp.git"
#PATCHES=""
ARCHITECTURES="x86_64"
PROVIDES="
QtQuickApp = $portVersion
"
REQUIRES="
haiku
"
BUILD_REQUIRES="
haiku_devel
cmd:qmake
"BUILD()
{
qmake .
make $jobArgs
}INSTALL()
{
make install
}Recipe Assembly
I save the file with the name QtQuickApp-1.0.recipe, after which I run aikuporter -S ./QuickApp-1.0.recipe. Checks dependencies for all packages in the repository which takes some time. I'll go and have a coffee.
And why on earth should this check be done on my local machine, and not centrally on the server 1 time for everyone?
According to mr. waddlesplash:
With such that you can overwrite any file in the repository π You can optimize it a bit by calculating the right information when you need it, because the last changes made are quite rare.
~/QtQuickApp> haikuporter QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
Error: QtQuickApp not found in repositoryIt turns out that there is no ordinary recipe file that contains the source code for your application. You need to keep it in the repository in the HaikuPorts format.
~/QtQuickApp> mv QtQuickApp-1.0.recipe ../haikuports/app-misc/QtQuickApp/
~/QtQuickApp> ../haikuport
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipeThis fact makes assembly more cumbersome. I don't really like it, but I think it's necessary so that eventually all open source software will appear in HaikuPorts.
I get the following:
~/QtQuickApp> haikuporter -S QtQuickApp-1.0.recipe
Checking if any dependency-infos need to be updated ...
updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
Error: QtQuickApp-1.0.recipe not found in tree.What's wrong? After reading irc I do:
~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: https://github.com/probonopd/QtQuickApp.git ...
--2019-07-14 16:12:44-- https://github.com/probonopd/QtQuickApp.git
Resolving github.com... 140.82.118.3
Connecting to github.com|140.82.118.3|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://github.com/probonopd/QtQuickApp [following]
--2019-07-14 16:12:45-- https://github.com/probonopd/QtQuickApp
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: β/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.gitβ
0K . 1.34M=0.06s
2019-07-14 16:12:45 (1.34 MB/s) - β/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.gitβ saved [90094]
Validating checksum of QtQuickApp.git
Warning: ----- CHECKSUM TEMPLATE -----
Warning: CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"
Warning: -----------------------------
Error: No checksum found in recipe!An interesting question arose. If I add a checksum to the recipe, will it match the latest git commit for continuous integration? (Developer confirms: "Nothing will work. Recipes are designed to be relatively stable.")
For fun, add to the recipe:
CHECKSUM_SHA256="cf906a65442748c95df16730c66307a46d02ab3a12137f89076ec7018d8ce18c"Still not satisfied:
~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
updating dependency infos of QtQuickApp-1.0
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------
Skipping download of source for QtQuickApp.git
Validating checksum of QtQuickApp.git
Unpacking source of QtQuickApp.git
Error: Unrecognized archive type in file /boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.gitWhat is he? After all, this is a git repository, the code is already there directly, there is nothing to unpack. From my point of view, the tool should be smart enough not to look for an unpacker if it is over a GitHub url.
Maybe uri git:// will work
SOURCE_URI="git://github.com/probonopd/QtQuickApp.git"Now it complains like this:
Downloading: git://github.com/probonopd/QtQuickApp.git ...
Error: Downloading from unsafe sources is disabled in haikuports.conf!Hmm, and why is everything so complicated, why not "just work"? After all, it's not uncommon to build something off GitHub. Whether it's tools that work right away, without the need for configuration, or as I call it "fuss".
Maybe it will work like this:
SOURCE_URI="git+https://github.com/probonopd/QtQuickApp.git"Nope. Still getting this dumb error and doing,
sed -i -e 's|#ALLOW_UNSAFE_SOURCES|ALLOW_UNSAFE_SOURCES|g' /boot/home/config/settings/haikuports.confI'm moving a little further, but why is it yelling at me (GitHub is not secure!) and still trying to unpack something.
According to :
Well, yes, the reason was the desire to check the integrity of the data received for the assembly. One of the options is to check the checksum of the archive, but you can, of course, hash individual files, which will not be implemented, because. it takes much longer. The consequence of this is the βinsecurityβ of git and other VCSs. This will most likely always be the case, since creating an archive on GitHub is quite easy and often faster. Well, in the future, perhaps the error message will not be so flashy ... (we no longer merge such recipes in HaikuPorts).
~/QtQuickApp> haikuporter -S QtQuickApp
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
----------------------------------------------------------------------
app-misc::QtQuickApp-1.0
/boot/home/haikuports/app-misc/QtQuickApp/QtQuickApp-1.0.recipe
----------------------------------------------------------------------Downloading: git+https://github.com/probonopd/QtQuickApp.git ...
Warning: UNSAFE SOURCES ARE BAD AND SHOULD NOT BE USED IN PRODUCTION
Warning: PLEASE MOVE TO A STATIC ARCHIVE DOWNLOAD WITH CHECKSUM ASAP!
Cloning into bare repository '/boot/home/haikuports/app-misc/QtQuickApp/download/QtQuickApp.git'...
Unpacking source of QtQuickApp.git
tar: /boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Command 'git archive HEAD | tar -x -C "/boot/home/haikuports/app-misc/QtQuickApp/work-1.0/sources/QtQuickApp-1.0"' returned non-zero exit status 2As an old habit, I go to ask kind people on the #haiku channel on irc.freenode.net. And where would I be without them? After prompting, I figured out what to use:
srcGitRev="d0769f53639eaffdcd070bddfb7113c04f2a0de8"
SOURCE_URI="https://github.com/probonopd/QtQuickApp/archive/$srcGitRev.tar.gz"
SOURCE_DIR="QtQuickApp-$srcGitRev"
CHECKSUM_SHA256="db8ab861cfec0ca201e9c7b6c0c9e5e828cb4e9e69d98e3714ce0369ba9d9522"Well, it became clear what it does - it downloads the archive with the sources of a certain revision. Stupid, from my point of view, and not quite what I wanted, namely, download the latest revision from the master branch.
One of the developers explained it this way:
We have our own CI, so anything put into the haikuports repository will be archived for all users, and we don't want to take the risk of building and shipping "everything upstream".
Understood! Anyway, this is what happened:
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
waiting for build package QtQuickApp-1.0-1 to be activated
(...)It repeats this ad infinitum. Apparently, this is a mistake (is there an application? I did not find it).
Π‘ haikuporter and repository It doesn't feel like it just works, but as a developer, there are some things I like about working with Haiku. For the most part, it's like the Open Build Service, a set of tools for building Linux builds: extremely powerful, with a systematic approach, but overkill for my small "hello world" application.
Again, according to mr. waddlesplash:
Indeed, HaikuPorter is quite strict by default (plus it has a lint mode, as well as a strict mode to make it even more strict!), but only because it builds packages that will work, not just build packages. That's why it complains about undeclared dependencies, libraries not properly imported, incorrect versions, and so on. The goal is to catch all problems, including future ones, without exception, before the user knows about it (that's why it was not possible to install avrdude, because the recipe actually specified a dependency). Libraries are not just individual packages, and not even specific versions of SO. HaikuPorter makes sure that all of these are observed in the recipes themselves to avoid runtime errors.
In principle, this level of rigor is justified when creating an operating system, but it seems to me redundant for a "hello world" application. I decided to try something else.
Building applications in hpkg format using the "package create" command
May be, Is a simple instruction better for me?
mkdir -p apps/
cp QtQuickApp apps/cat > .PackageInfo <<EOF
name QtQuickApp
version 1.0-1
architecture x86_64
summary "Demo QtQuick application"
description "QtQuickApp is a demo QtQuick application for testing Haiku porting and packaging"
packager "probono"
vendor "probono"
copyrights "probono"
licenses "MIT"
provides {
QtQuickApp = 1.0-1
}requires {
qt5
}
EOFpackage create -b QtQuickApp.hpkg
package add QtQuickApp.hpkg apps# See below if you also want the application
# to appear in the menuUnexpectedly fast, unexpectedly simple, unexpectedly effective. Just the way I like it, amazing!
Installation - what and where?
Moved QtQuickApp.hpkg file to ~/config/packagesusing the file manager, after which QtQuickApp magically appeared in ~/config/apps.
Again, unexpectedly fast, simple and effective. Amazing, incredible!
But ... (where without them!)
The app is still missing from the app menu list and QuickLaunch. I think I already know how to fix it. In the file manager I move QtQuickApp.hpkg from ~/config/packages to /system/packages.
Nope, still missing. Apparently, I (well, the instructions) missed something.
Looking at the "Contents" tab in HaikuDepot for some other applications, I saw that there are files like /data/mimedb/application/x-vnd... what is even more remarkable /data/deskbar/menu/Applications/β¦.
Well, what should I put in there? Well...
mkdir -p data/deskbar/menu/Applications/
( cd data/deskbar/menu/Applications ; ln -s ../../../../apps/QtQuickApp . )
package add QtQuickApp.hpkg apps dataI am quite sure that this trick will work, but questions remain: why is this needed, what is it for? In my opinion, this destroys the overall impression that the system is so sophisticated.
As explained by mr. waddlesplash:
Sometimes there are apps that other apps need but not in the menu. For example, the LegacyPackageInstaller in your screenshot handles BeOS format .pkg archives. I would like users to set them, but their presence in the menu will lead to confusion.
For some reason it seems to me that there is a simpler solution, for example Hidden=true in files .desktop on Linux. Why not make "hidden" information a resource and an attribute of the file system?
What is not particularly subtle is the name of a (some) application that displays a menu, deskbar, hardwired in the way.
mr. waddlesplash explains this:
"Deskbar" in this case should be understood as a general term (much like "taskbar", referring to both a Windows application and a general concept). Well, since this
deskbar, and not "Deskbar", this can also be understood in a similar way.
2 "almost identical" directories with applications in them
Why are there 2 application directories, and why is my QtQuickApplication in one and not in the other? (After all, this is not one system, but the second user, which I personally would understand).
I'm really confused and I think that it would be necessary to unify this.
comment mr. waddlesplash
There are applications in the Apps directory that are not needed in the menu. But the situation with the menu really needs to be improved, made more customizable.
Application or it won't happen π
I thought: is it really necessary to place applications in /system/apps, if users see them there, it is undesirable. Maybe it's better to place them in another place where the user will not encounter them? Just as it is done in Mac OS X, where the contents of the packages .app, which should not be visible to the user in /Applications, hides in the bowels of /System/Library/β¦"`.
What about dependencies?
I think it's worth specifying the dependencies somehow, right? Can Qt be considered a mandatory part of the default Haiku installation? Nope! Qt is not installed by default. Can the package builder automatically detect dependencies by checking ELF files? I was told that HaikuPorter does indeed do this, but here package No. That's because it's just a "package builder", which by itself just creates files hpkg.
Should Haiku be refined by adding a policy that a package should not have dependencies on packages outside of haikuports? (I'd love to, since such a policy makes things a lot easier - the system could automatically resolve the dependencies of every package downloaded from anywhere, without fiddling with additional package sources.)
mr. waddlesplash explains:
We don't want to limit the freedom of developers so much, because it is obvious that if CompanyX wants to maintain its own set of software with dependencies (and therefore a repository) - it is completely free to do so.
In such a case, it might be worth recommending that third party packages avoid dependencies on anything not included in haikuports by fully packaging everything needed with the application. But I think this is a topic for a future article in this series. [Author tending to AppImage? - approx. translator]
Adding an Application Icon
But what if I want to add one of the neat built-in icons to the resources of my freshly created application? It turns out that this is an amazing topic, so it will be the main one for the next article.
How to organize continuous assembly of applications?
Imagine a project like Inkscape (yes, I know it's not in Haiku yet, but it's handy to show on). They have a source code repository https://gitlab.com/inkscape/inkscape.
Every time someone commits their changes to the repository, build pipelines are started, after which the changes are automatically tested, built, the application is packaged in various packages, including AppImage for Linux (a standalone application package that can be downloaded for local testing, regardless of what may or may not be installed on the system [I knew it! - approx. translator]). Similarly, this happens with every pull request, so it is possible to download an application built from the code proposed in the pull request even before the merge.
Pull requests with build statuses and the ability to download built binaries if the build is successful (marked in green)
The build runs in Docker containers. GitLab offers free runners on Linux, and I think it's possible to add custom runners (btw, I don't see how this would work for systems like Haiku, which I know don't have Docker or equivalent, but FreeBSD also no Docker, so this issue is not unique to Haiku).
Ideally, Haiku applications can be built inside a Linux Docker container. In this scenario, the assembly for Haiku can be injected into existing pipelines. Any cross compilers? Or do I need to emulate the entire Haiku inside a Docker container using something like QEMU/KVM (assuming it works that way inside Docker)? By the way, many projects use similar principles. For example, Scribus does this - it's already available for Haiku. One day the day will come when I can send pull requests to other projects to add support for Haiku.
One developer explains:
For other projects that want to package their own, the usual CMake/CPack method is supported. Other build systems can be supported by calling the package builder directly, which is fine if people are interested. Experience shows that there hasn't been much interest so far, so haikuporter has worked to our advantage, but in the end both ways should work together. We should introduce a set of tools to cross-build software from Linux or any other server operating system (Haiku is not designed to run on servers).
I applaud standing. Ordinary Linux users carry all this extra workload and extra baggage (security, tight control, etc.) that a server OS needs, but not a personal one. Therefore, I fully agree that being able to build applications for Haiku on Linux is the right way to go.
Conclusion
Porting POSIX applications to Haiku is possible, but may be more expensive than a simple rebuild. I would definitely be stuck with this for a long time if it wasn't for the help of the #haiku people on irc.freenode.net. But even they did not always immediately see what was wrong.
Applications written in Qt are an easy exception. I put together a simple demo application without too much trouble.
Building a package for simple applications is also quite easy, but only for "traditionally released", i.e. having versioned archives of source code intended for support in haikuports. For a continuous build (build per commit) with GitHub, things seem to be not so simple. Here, Haiku feels more like a Linux distribution than it does on a Mac, where pressing the Build button in XCode results in a package. .app, ready to be inserted into a disk image .dmg, prepared for upload on my site.
Continuous building of applications based on a βserverβ operating system, such as Linux, will most likely become possible if there is demand from developers, but at the moment the Haiku project has other, more pressing tasks.
Try it yourself! After all, the Haiku project provides images for booting from DVD or USB, generated . To install, just download the image and burn it to a USB flash drive using
Got questions? We invite you to the Russian-speaking .
Error overview:
From Translation: This is the fifth article in the Haiku series.
List of articles:
Source: habr.com