That’s what it got at the moment, the package name: llvm17${secondaryArchSuffix}_clang
It’s not used in build time, nor linked to Genio, so my guess is that Genio requires cmd:clang for it’s development rather then lib:libclang (as my initial comment went).
So replacing llvm17${secondaryArchSuffix}_clang with cmd:clang in the recipe will use the available command to run it’s functions.
From its homepage:
strongly recommended for full Genio experience (autocompletion, jump to definition, etc):
- gcc_syslibs_devel
- llvm17_clang
There’s an option to build it with clang, but I don’t see that used in the recipe. Those two packages are not really needed to build it. For the LSP feature, the command used is clangd.
From Configuring-clangd-lsp.md:
latest LLVM (clang) (at the time of writing is version 17)
So even the version number may just be “this is the latest version and the one we have tested with”. Looking at the history of those documents, one can see at one point it was version 12 and nothing else seems to have changed around then to require that jump.
2 Likes
clangd works too 
inrecipe cmd:clangd
/Opslag/haikuports/sys-devel/llvm/llvm12-12.0.1.recipe:351: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm16-16.0.6.recipe:298: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm17-17.0.6.recipe:295: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm18-18.1.2.recipe:301: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm18-18.1.6.recipe:301: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm18-18.1.7.recipe:301: cmd:clangd = $portVersion
/Opslag/haikuports/sys-devel/llvm/llvm9-9.0.1.recipe:313: cmd:clangd = $portVersion
pkgman search cmd:clangd
Status Name Description
-------------------------------------------------------------------------------
llvm12_clang Modular and reuseable compiler and toolchain technologies
llvm16_clang Modular and reuseable compiler and toolchain technologies
llvm17_clang Modular and reuseable compiler and toolchain technologies
s llvm18_clang Modular and reuseable compiler and toolchain technologies
llvm9_clang Modular and reuseable compiler and toolchain technologiesThis looks similar to the CudaText / Python situation.
If it is not a hard requirement at runtime (as Python wasn’t in CudaText case), I think the Genio package should not require clangd (after all, one might want to use Genio, say, only for Python development).
Sure… same as with CudaText (if you don’t have any Python installed), you’re limiting its capabilities, but at least you’re not forced to install packages users might not want/need.
For me, the issue here is the lack of a working “suggests/proposes/recommends” mechanism on PackageKit/pkgman side, so you could do something like:
pkgman search --recomends genio to get the list of packages it might use, and pkgman install --recomended genio to install all of them along with genio.
5 Likes
Then maybe just leave the requirement out in the recipe as we did for CudaText, did a check with cmd:clangd in the recipe, then it seems it can either use llvm17_clang or llvm18_clang (llvm12_clang and llvm16_clang will take both the installed clang package and genio down when trying to install).
1 Like
Just for interest’s sake, apt-get works the other way round: by default it installs everything, but it has --no-install-recommends and --no-install -suggests switches.
Either way can work, but we’d have to think closely on what we want the default situation to be in Haiku, because mixing the approaches would just be horrible.
Alternatively, you could have a first-run dialog : “Thanks for installing/updating XXXXX. Would you also like to install any of the following optional packages?” That is well within the possibilities of the pkgman system as we have it. Code it as a separate applet and run it from a script in /boot/system/boot/post-install, and if the main program is a port, you wouldn’t even need to bother upstream about it.
3 Likes
Perhaps, in this case, asking users would be the best solution as it allows to offer multiple choices depending what language they intend to use.
1 Like
I could imagine that haikudepot might offer variants off a package, in essence defined different package arrangements.
You might download Genion and choose the variant (or flavor) bare-bones or fully-featured, and it would then pull in dependencies based on that, instead of having random “suggested” packages where the user has no idea what is needed and what isn’t.
I dropped the same simular requirements for Geany back then, those can always be installed by the user when needed, I guess a user is clever enough if they want a language to code it they would know how to install them?
1 Like
Is it possible to have Genio run pkgman itself if a feature or option is needed that requires something that isn’t already installed?
Don’t see why not. It’s just a system call and in a native app we can do what we like.
But we do need to think of a general policy, including for ports, Lots of IFDEF blocks that only apply to one operating system don’t endear you to the upstream devs.
1 Like
Dropping the dependency is probably the right thing to do.
In the future we’ll try to add some way to install additional / missing components from within Genio itself, using haiku packages, of course.
2 Likes
I think we could change the Genio 2.1 recipe as you suggested. For the next release, I guess we’ll drop the dependency completely. What do you think ?
1 Like
Sounds like the right thing to do, at this moment LLVM18 isn’t available yet, but this also blocks being able to checkout clangd with LLVM16 (probably not worth it - playing devils advocate ).
Can you do a PR for this?
2 Likes
Merged, thanks for this! 
1 Like
How does Debugger figure out and request necessary packages to install? Perhaps Genio could also reuse that to some extent.
Nothing special really. If you need a lib called libsomething.so you can use "pkgman install “lib:libsomething” which is easily deduced from the library name (that’s the point of these lib: and cmd: entries)
What’s weird is that pkgman install cmd:clang on beta4 installs llvm12 instead of the latest version.
It’s because that is the first one it encounters? You can install llvm17 with pkgman which will replace llvm12, when llvm18 hit’s the scene it’s just as easy to switch the clang package, now it’s not “tied” to any particular version.
EDIT: use “pkgman install llvm17_clang” (for 64bit)
EDIT2: “pkgman install llvm17_x86_clang” (for 32bit)