Cmake is not my cup of tea

x265 build system is based on cmake.
A particular script named Version.cmake should scan and find information about version of the lbrary and include those into the build, and in a statement it seeks for git:

find_package(Git QUIET)

Now, this never catches the git binary (I double checked: git is there, version 2.37.3 and when I remove that “QUIET” a string tells me git was not found) and the result is the version information is lost. How can I see how this script fails?

Further, into /boot/system/data/cmake/Modules I see a FindGit.cmake which gives:

cmake -P FindGit.cmake
-- Found Git: /bin/git (found version "2.37.3")

so, if I manage to replace that find_package command with this, it will surely find git.
How will I?

Are you trying to build x265 with haikuporter?

Yes exactly (forgot to mention, sorry)

Does your recipe declares git as build-time dependency?
Is git actually attached to the chroot?
What happens if you invokes “git --version” in the first line of the BUILD() section?

The block BUILD_PREREQUIRES has git commented out (statement 54)

How to check for this?

haikuporter fails because git is not found.

What happens, if you remove the hashmark?

Haikuporter shows a list about the packages which is activated in the chroot every time you try to build a recipe.

So for some reason x265 now requires git. Either patch it out or add git to the build-time-dependency list (remove the hashmark).

It seems you dont understand how haikuporter works. Please spend more time with the HaikuPorter documentation: Home · haikuports/haikuports Wiki · GitHub

Don’t know what you try to build, but even with cmake builds pkg-config is checked, so maybe add “cmd:pkg_config$secondaryArchSuffix” to BUILD_PREREQUIRES ?

EDIT add -L to cmake during build shows available options, and check the logs :slight_smile:

Talking about cmake… I’m repeatedly getting into trouble with the way how haikuporter sets $cmakeDirArgs.

In particular: CMAKE_INSTALL_DATADIR, CMAKE_INSTALL_LIBDIR, CMAKE_INSTALL_MANDIR etc are configured as absolute paths while many projects rely on these being relative paths.

Is there any particular reason for this (apparently not so common) behavior?

some examples:

  • manpage install in libpcap, CMAKE_INSTALL_MANDIR is concatenated with CMAKE_INSTALL_PREFIX
  • rpath in audacity and tenacity uses CMAKE_INSTALL_LIBDIR as part of a relative path
  • wireshark: CMAKE_INSTALL_DATADIR is concatenated with CMAKE_INSTALL_PREFIX

I was reluctant to raise it as an issue in haikuporter github repo as I’m not sure if this is a bug or a design decision.

1 Like

Probably I just copied most of the logic from runConfigure / $configureDirArgs and didn’t think too much about it. Please do work on fixing this, though be sure to test with any recipe that uses them already.


That would be rather difficult as it seems there are more than 100 packages already using $cmakeDirArgs.

Can we perhaps introduce a new variable $cmakeDirArgsRelative?

I meant “any” as in “at least one”, not “all.” These variables are really supposed to be processed by the GNUInstallDirs module, which I think handles both relative and fixed paths, so it may only be applications which don’t use GNUInstallDirs that we need to think about here?

How do you handle haikuporter updates on the builders? My PR for relative CMake dirs have been merged in haikuporter repo, so can I submit recipes that rely on this change? Or should I wait for a new haikuporter package release/

I think the builder needs to be manually updated and does not use the haikuporter package. It’s still a good idea to tag a new version of haikuporter from time to time, however, since not everyone runs it from the git repo.

Indeed a system administrator has to update the haikuporter version on the builders. I can do that later today, I think.

1 Like

HaikuPorter now updated on the builders.

I left a comment on the cmakeDirArgs change commit, though, did you see that?

1 Like