TL; DR: Newbie sees Haiku for the first time, tries to port some programs from the world Linux.
My first Haiku port packaged in its hpkg format
I discovered Haiku, an unexpectedly good PC operating system.
Today I'll be learning how to port new programs to this operating system. The main focus is describing my first experience switching to Haiku from a developer's perspective. LinuxI apologize for any silly mistakes I made along the way, as it hasn't even been a week since I first downloaded 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:
- Our 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. It's mostly similar to the Open Build Service—a set of tools for building builds. Linux: extremely powerful, with a systematic approach, but overkill for my small "hello world" level app.
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 + LinuxWhy not make the "hidden" information a resource and a file system attribute?
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 (approximately the same as "taskbar", which refers to both an application Windows, and to the general concept). Well, since this is
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 triggered, after which the changes are automatically tested, built, and the application is packaged into 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 also think it might be possible to plug in custom runners (by the way, I have no idea how this would work for systems like Haiku, which I know don't have Docker or anything like that, but FreeBSD doesn't have Docker either, so this issue isn't unique to Haiku).
Ideally, building applications for Haiku can be done inside a Docker container for LinuxIn this scenario, building for Haiku can be integrated into existing pipelines. Are there cross-compilers? Or should I 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, I'll be able to send pull requests to other projects to add support for Haiku.
One developer explains:
For other projects that want to create their own packages, the standard CMake/CPack method is supported. Other build systems can be supported by invoking the package builder directly, which would be nice if people were interested. Experience shows that there hasn't been much interest so far, so haikuporter has worked for us, but ultimately, both methods should work together. We should introduce a set of tools for cross-building software from Linux or any other server operating system (Haiku is not designed to run on servers).
Standing ovation from regular users Linux They carry all this extra load and baggage (security, strict control, etc.) that a server operating system needs, but not a desktop one. Therefore, I completely agree that the ability to build applications for Haiku on Linux — the right way.
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" applications, meaning those with versioned source code archives intended for support in haikuports. For continuous builds (building for every commit), things aren't quite as straightforward with GitHub. Here, Haiku feels more like a distribution. Linux, than the result on Mac, where clicking the "Build" button in Xcode produces a package .app, ready to be inserted into a disk image .dmg, prepared for upload on my site.
Continuous assembly of applications based on the "server" operating system, for example, Linux, will 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
